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Preface 



CAiSE 2004 was the 16 th in the series of International Conferences on Advanced 
Information Systems Engineering. In the year 2004 the conference was hosted by 
the Faculty of Computer Science and Information Technology, Riga Technical 
University, Latvia. 

Since the late 1980s, the CAiSE conferences have provided a forum for the 
presentation and exchange of research results and practical experiences within 
the field of Information Systems Engineering. The conference theme of CAiSE 
2004 was Knowledge and Model Driven Information Systems Engineering for 
Networked Organizations. 

Modern businesses and IT systems are facing an ever more complex envi- 
ronment characterized by openness, variety, and change. Organizations are be- 
coming less self-sufficient and increasingly dependent on business partners and 
other actors. These trends call for openness of business as well as IT systems, 
i.e. the ability to connect and interoperate with other systems. Furthermore, 
organizations are experiencing ever more variety in their business, in all con- 
ceivable dimensions. The different competencies required by the workforce are 
multiplying. In the same way, the variety in technology is overwhelming with a 
multitude of languages, platforms, devices, standards, and products. Moreover, 
organizations need to manage an environment that is constantly changing and 
where lead times, product life cycles, and partner relationships are shortening. 
The demand of having to constantly adapt IT to changing technologies and busi- 
ness practices has resulted in the birth of new ideas which may have a profound 
impact on the information systems engineering practices in future years, such as 
autonomic computing, component and services marketplaces and dynamically 
generated software. 

These trends pose a number of challenges to both the operational systems 
and the development processes of the organization, its work practice, and its IT 
systems. In order to cope with increasingly complex business and IT environ- 
ments, organizations need effective instruments for managing their knowledge 
about these environments. Essential among these instruments are models, i.e. 
representations of aspects of reality including the domain of work, the processes, 
and the context. Models come in a variety of forms, formal or informal; describing 
static or dynamic aspects; representing agents, processes, or resources; focusing 
on business or IT aspects, etc. To realize the full potential of models, there is 
a need for a business and technology architecture as well as a way of working 
that places the models firmly in the center and lets them be the driving force in 
analysis, design, implementation, deployment and use of systems and services. 
This implies developing not only new modeling languages but also new ways of 
developing models, which incorporate in a participatory manner all stakeholders 
involved. 
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Preface 



The challenging theme of CAiSE 2004 attracted scientists from all over the 
world to submit their contributions. The total number of submissions was 160, 
out of which the program committee selected 39 top-quality papers. The result- 
ing program reflects the fact that the topic of information systems engineering 
encompasses human and organizational issues as well as technical issues. In ad- 
dition to the main program, 16 papers presenting emerging ideas were invited to 
the CAiSE Forum. The CAiSE Forum was initiated by the organizers of CAiSE 
2003 in Velden as a means of stimulating scientific debate. 

The success of the CAiSE conferences is shown by the large number of co- 
located events. CAiSE 2004 was accompanied by eleven workshops and four 
tutorials, which attracted a large number of participants. The tutorials were 
given by Scott Ambler (Canada), Brian Henderson-Sellers (Australia) and Dov 
Dori (Israel). In addition, the Sixth International Baltic Conference on Databases 
and Information Systems was co-located with CAiSE 2004. 

We devote a special thanks to the members of the program committee for 
providing excellent reviews of the submitted papers. Their dedicated work was 
instrumental in putting together yet another high-quality CAiSE conference. 
We wish also to give special thanks to the local organizers at the Riga Technical 
University for their hard work and devotion, which made the conference a great 
success. 

The CAiSE 2004 organizers would also like to thank the conference sponsors - 
the Latvian Council of Science, the Dati Group (Latvia), Tieto Enator (Latvia), 
Lattelekom (Latvia), and the SISU Foundation (Sweden). 
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Modelling in Information Systems Engineering 
When It Works and When It Doesn’t 
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This talk will reveal two secrets. 

The first secret is that it is not due to lack of formal methods or inappropriate for- 
malisms that roughly 50% of all implemented system functionality is thrown away 
even before the roll out of the systems concerned - and 70% of the rest is unused after 
some two years in production. 

The second secret is that today, if you make a small effort, you will learn how to 
beat 80% of the consultants on the market when it comes to modelling processes - 
just by a simple twist of perspective. 

The aim of this talk is to make you less easy to fool and to give some hints con- 
cerning potentially profitable research directions as well as some inspiration for fur- 
ther thinking. A basic assumption is that businesses as well as academia exist to create 
value. After some 25 years of experience in commercial modelling, this leads to some 
questions concerning general aims and basic paradigms in research and practice. 

In my opinion, the academician has an extremely important role to play, but some- 
thing seems to have gone wrong. The basic reason might be that, paradoxically, the 
concept of information as well as the consequences of its proper definition seems to 
be more or less completely disregarded in information science. Naturally, this leads to 
severe misconceptions concerning the relevant problems to attack. As a further con- 
sequence, academic structures often represent a real mismatch with respect to neces- 
sary interdisciplinary cooperation. 

(Yes, yes, of course, there is a plethora of definitions of information.) 

In my opinion, the practitioner in modelling has avoided responsibility and real in- 
fluence by being too narrowly focused. Modelling as an art has often deteriorated to 
simple description. While simple design instruments are used analytical instruments, 
if they are at all known, are not. Moreover, in some cases, commercially developed 
methods are sometimes downright dangerous to put in the hands of the normal ana- 
lyst. Finally, inviting disaster, the modeller at large has limited abilities and instru- 
ments for the necessary cooperation with management and business development 
representatives. 

There are, however, some remedies available 
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We are currently observing that formerly “large” information systems development 
and integration projects are becoming “smaller and smaller”. This trend is somewhat 
related to key performance indictors and other business targets that are today set for 
top and middle management of traditional customers for such projects. Today an 
average business line manager of a medium size company is very much concerned 
about meeting personal scorecard goals that are in many cases measured by different 
industry specific performance indicators and in some cases purely financial ratios. 
Translation of typical indicators into IT development and integration project goals and 
objectives really makes the difference. There are very few incentives for a line man- 
ager to be involved with an IT integrator into a multiyear project involving thousands 
of man days and huge financial resources, thus bearing related risks. In turn there is a 
growing need for component based solutions that could be developed and rolled out in 
short lifecycles with limited resource requirements. 

We are facing a similar trend in the public sector working with e-government pro- 
jects. Here, as a rule, we are working for top level government or municipality offi- 
cials that expect to demonstrate to the general public tangible project results every 
budget period or at least before the next election campaign starts. These expectations 
from business customers as well as government sector customers are challenging IT 
industry players to come up with project structures and management approaches that 
deliver much shorter planning-to-rollout cycles and ability to integrate components of 
different business solutions. 
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Abstract. Over the past decade, continuous challenges have been made to tradi- 
tional business practices. At the same time, organisations have also experienced 
the effects of the integration and evolution of information and communication 
technologies (ICT). The Enterprise Information Systems (EIS) gained a new 
strategic support role as enabler of automation, monitoring, analysis and co- 
ordination of whole business functioning, a central role in the evolution of to- 
day organisations. These rapid changing situations originate a critical need for 
realistic representations -called business models- of what are the current or fu- 
ture business situations or what should be changed as well as its potential or- 
ganisational impacts. This paper characterises the strong relationship existing 
between Business Models and EIS Architectures in a changing environment. 
Our main contribution is a set of roadmaps, which highlight the relationships 
between business process models and the requirements of EIS. These roadmaps 
provide guidance during the business modelling and the information system 
(IS) modelling processes. 



1 Introduction 

The last twenty years, the evolution of Information and Communication Technologies 
(ICT), along with the search for management strategies that could take advantage of 
them, are pushing organisations into a very competitive and changing environment. 
Rapid market changes such as electronic commerce, deregulation, globalisation and 
increased competition have led to a business environment that is constantly evolving. 
Companies change to better satisfy customer requirements, address increasingly 
tough competition, improve internal processes and modify the range of products and 
services they offer [ 1 ] . While information systems (IS) continue to serve traditional 
business needs such as co-ordination of production and enhancements of services 
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offered, a new and important role has emerged for them. ICT are thus positioned as a 
strategic resource that enables automation, monitoring, analysis and co-ordination to 
support the transformation of business processes [2], 

In that sort of environment, only those organisations, which can react quickly to 
environment demands, are the ones that survive. That capacity of quick reaction is 
often due to their capacity of handling ICT in favour of the business evolution re- 
quirements. ICT and management go hand by hand in the way of reacting, adapting 
and implanting new ways of doing business in today dynamic environments. IS are 
thus not just supporting businesses; they are an integral part of them. 

All these ICT and management changes have imposed serious challenges to tradi- 
tional business practices. For instance, in a competitive and evolving environment, 
quality became a fundamental key to obtain and to keep market share [3]. Another 
important wave in the evolution of management strategies was the Business Process 
Reengineering [4], which consists of a radical remodelling of the organisation around 
its processes 1 . In all these management challenges, the ICT and the EIS act as facilita- 
tors of business changes implementation and standardisation. 

In the field of Information Systems, the notion of “Enterprise modelling” refers to 
a collection of conceptual modelling techniques for describing different facets of the 
organisation including operational (IS), organisational (business processes, actors, 
flow of information etc), and teleological (purposes) considerations [5]. Existing 
enterprise modelling frameworks [6], [7], [8], ([9], [10], [11], [12] and [13] stress the 
necessity of representing and structuring enterprise knowledge taking into account all 
these facets in order to develop IS and IT architectures that enterprises need. 

In order to take business through a well managed change process, the organisation 
needs to strike a balance between the technical and the social organisational levels; 
i.e. there must be a consolidation of the diversity of perspectives that stakeholders, 
managers, and IS engineers have about the business and the way organisation must 
change. 

The work presented in this paper concerns principally the need of methods provid- 
ing guidance while the transformation process takes place. We present an extension 
of the EKD-CMM 2 method previously presented in [14], [15], [4], [16], [17], [18], and 
[T9]. This extension provides a clear and complete picture of what are the main ac- 
tivities related with the definition of IS architectures in a dynamic and evolving envi- 
ronment. Considering that our approach is requirements driven, we describe the way 
of moving from business processes to EIS architecture and from ICT requirements to 
business process redesign. 

This paper is organised as follows. In Section 2, we present the concepts associ- 
ated to our representation of an enterprise model. We made special emphasis on the 
relationships between business processes and IS. Section 3 presents the concepts 
associated to the IS architecture of an organisation. We highlight those elements that 



1 A set of activities which produces, from one or several inputs, an output valuable for the 
customer. 

2 The term EKD-CMM stands for Enterprise Knowledge Development-Change Management 
Method. 
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are more vulnerable to environment changes. This section presents also the modelling 
needs for those who define the IS architecture of an organisation. The guidance offer- 
ing a methodological response to these needs is expressed by roadmaps that show a 
set of alternative ways of moving from business processes to IS architecture. Section 
4 illustrates an example of path for the specification of an IS model through the con- 
ceptualisation of the enterprise process model. Finally, section 5 concludes the paper. 



2 Business Modelling through EKD-CMM 

As introduced before, the recent transformations in economical and ICT environ- 
ments have imposed radical changes in the way business is driven nowadays. There is 
an increasing need for ICT support in achieving competitive business goals. Exam- 
ples of this are the Enterprise Application Integration (EAI) approach, the Enterprise 
Resources Planning (ERP), and the e-Business [20], among the most known. 

Analysing these innovative approaches, we found that they are based on a common 
business driver: “the urgency of adapting business to the dynamical environment 
demands”. This adaptation must be made by taking into account not only the internal 
processes and ICT exigencies, but considering the reasons that caused the change 
process. For example, if the change is caused by a modification in business goals 
because of a predefined surviving strategy, then the change problem must be analysed 
in a top-down manner. In this case, the ICT technologies must act as a support for the 
decision making process and also as a solution for implementing and consolidating 
change in the organisation. The perspective for analysing the change process is dif- 
ferent if the origin of change is at the IS layer, i.e. if the change process is caused by 
the introduction or modification of some ICT technologies. In that case, the change 
situation must be analysed in a bottom-up manner so the advantages for the whole 
business can be elicited. In this case, the ICT is a cause of the business change, thus 
its impacts must analysed from many perspectives. For instance, the IS Architecture, 
as well as the way business processes are organised and executed, may change. 

These two complementary examples of the ICT role in a business transformation 
process aim to help us to state that the relationships between business processes and 
IS are the nucleus of a successful organisational change process. In other words, it 
does not matter what causes the change process. What it is relevant is how well the 
relationships between business functioning and ICT are characterised and imple- 
mented. This characterisation will allow business managers to visualise, analyse and 
implement business changes without neglecting the crucial effects that ICT have over 
business functioning and vice versa. Moreover, models facilitate understanding and 
communicating about the business and its support systems only if the objective of the 
model is well understood. For instance, if the objective is to understand the business 
well enough to specify supporting systems, it is not useful to model the entire busi- 
ness in detail. Contrary, if the aim is to innovate the business, it is necessary to pro- 
vide more effort to define and/or redefine the entire business and to find improved 
ways of conducting it [18], [14]. 
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2.1 A Survey of EKD-CMM Method 

EKD-CMM is a method for documenting an enterprise, its objectives, business proc- 
esses and support systems, helping enterprises to consciously develop schemes for 
implementing changes. EKD-CMM satisfies two requirements: (i) assisting enterprise 
knowledge modelling and (ii) guiding the enterprise modelling and the organisational 
transformation processes. 

The EKD-CMM enterprise knowledge modelling component [14], [15], [21], [18], 
[16] recognises that it is advantageous to examine an enterprise from multiple and 
inter-connected perspectives. Thus, EKD-CMM models describing an enterprise are 
structured in three layers of concern (see Figure 1): Enterprise Goal Model, Enter- 
prise Process Model and Enterprise Information System Model. The first two layers 
focus on intentional and organisational aspects of the enterprise, i.e. the organisa- 
tional objectives and how these are achieved through the co-operation of enterprise 
actors manipulating such enterprise objects. The third layer is useful when the EKD- 
CMM approach is applied to define the requirements for the IS supporting the enter- 
prise. 

The result of applying EKD-CMM method is an enterprise model, which repre- 
sents a set of operational (information systems), organisational (business processes) 
and intentional (business objectives) models describing several views of the organisa- 
tion. 




Fig. 1 . EKD-CMM enterprise representation layers 



From the point of view of method engineering, an enterprise model is a product 
[22], [23]. In fact, the product is the desired output of the design process, whereas the 
process keeps track of how the product has been constructed. A Product Model de- 
fines the set of concepts and their relationships that can be used to build a product, 
i.e., in our case, to build a model representing a given enterprise. The Process Model 
defines how to use the concepts defined within a Product Model. A Process Model 
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and its related Product Model 3 are specific to a method. The EKD-CMM Product and 
Process Models, according to method engineering principles, have been previously 
presented in [18], [19], [24], [25] and [26]. 

The intention oriented modelling used in EKD-CMM provides a basis for under- 
standing and supporting the enterprise modelling, and the managing the organisa- 
tional changes. At the same time, it helps to define the supporting IS. Process guid- 
ance provided by EKD-CMM is based on the map formalism [27], which is a 
navigational structure in the sense that it allows the modellers to specify paths from 
Start intention to Stop intention. The approach suggests a dynamic construction of the 
most appropriate path by navigating in the map. Thus, EKD-CMM proposes several 
ways of working, and in this sense, it is a multi-method. In fact, using the EKD- 
CMM framework, one can start at any enterprise representation layer and move on to 
other layers, depending on the modelling and organisational situations. 

The method may be used for both business engineering and IS engineering pur- 
poses, permitting: (a) Business process reengineering : from business processes layer 
to the business objectives for change [11], [14], [28], [29] and then to the business 
process architecture for the future; (b) Reverse engineering: from legacy information 
systems at the IS layer to the business processes layer [30], [31]; (c) Forward engi- 
neering or information system design: from business objectives to business process 
modelling and to the choice of the processes to be supported by the information and 
communication technologies (ICT) and than to the IS modelling [19]; (d) Business 
process improvement: by modelling and analysing the business processes in order to 
enhance them by specific modifications such as role definition or activity flow; (e) 
Quality management: by defining the business processes and quality procedures and 
by aligning them, ones with respect to others. 

The EKD-CMM three layers framework and the associated Process Model allow 
us to understand, to analyse and finally to model the enterprise according to its multi- 
ple perspectives, i.e. its strategy, its structure, and its IT strategy and support systems, 
in a global, interrelated and guided manner. 

During our previous work, we were particularly interested in the definition and 
modelling of the organisational change processes. To this end, we focused our atten- 
tion on business processes to understand the current way of working of the enterprise 
(second layer in Figure 1) and reasoned on the organisational change at the inten- 
tional level [14], [28], [29]. The EKD-CMM approach has been thus successfully 
applied in an ESPRIT Project (ELEKTRA) aiming to discover generic knowledge 
about change management in the electricity supply sector for reusing it in similar 
settings. Two end-user applications have been considered within the project. Our 
conclusion at the issue of these two real life projects was that reasoning on the enter- 
prise objectives makes easier understanding of problems and communication on es- 
sential aspects ( what and why instead of who, when, where and how). Our current 
work focuses on the two lower layers shown in Figure 1, namely business processes 



3 We use capitalised initials in order to differentiate the method specific Models from the 
application specific models (for instance a business model) that compose the product. 
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and information systems in order to highlight the relationships between the enterprise 
process models and the specifications of the ICT systems. 



2.2 EKD-CMM Product Models 

A business model can act as the basis for designing the supporting software systems 
in an enterprise. Typically, business modelling and software modelling use different 
languages and concepts making integration of the two models difficult [32]. The set 
EKD-CMM Product Models aims to ease this integration by providing methodologi- 
cal tools to use a business model (enterprise goal model and enterprise process mod- 
els) to define the supporting IS’ architecture. 

From the EKD-CMM perspective and experience, an important conclusion about 
business models use, is that it has a twofold goal: first, a model helps organisational 
members to understand what they are, what they want to be as an organisation, and 
how they can achieve an identified set of business goals by reorganising or 
(re)defining the business processes. Second, a model aims to design the IS architec- 
ture that best fits organisational needs already expressed by the business goals and 
their corresponding business processes. 

The instantiation of the Product Model’s concepts allows business modellers to 
build specific business models, which represent particular business situations. Let us 
suppose that the future business has been modelled from different perspectives (see 
[18] and [25] for details), i.e. by modelling the business goals, the actors that are 
responsible for the execution of the underlying business processes and the set of ac- 
tivities that are under the responsibility of those actors, as well as the resources in- 
volved in the execution of those activities. The resulting business models are in- 
stances of the Goal Model, the Actor/Role Model, the Role/Activity Model and the 
Business Object Model with their relationships. 



2.3 EKD-CMM Process Model 

A map [27] is a Process Model in which a non-deterministic ordering of intentions 
and strategies has been included. It is a labelled directed graph with intentions as 
nodes and strategies as edges between intentions. A map consists of a number of 
sections each of which is a triplet < source intention /, target intention I., strategy S r >. 
The map is a navigational structure that supports the dynamic selection of the inten- 
tion to be achieved next and the appropriate strategy to achieve it whereas the associ- 
ated guidelines help in the achievement of the selected intention. 

The EKD-CMM high-level map, shown in Figure 2, contains a finite number of 
paths; each of them is a EKD-CMM Process Model. Therefore the EKD-CMM map is 
a multi-model. None of the finite set of models included in the map is recommended 
‘a priori'. Instead the approach suggests a dynamic construction of the actual path by 
navigating in the map. In this sense the approach is sensitive to the specific situations 
as they arise in the modelling process. The EKD-CMM multi-model allows us to 
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express all modelling strategies that can be followed to build an enterprise model (a 
business model and an IS model). The formalisation used to define the EKD-CMM 
Process Model is intention oriented, i.e. the business owners’, the business modellers’ 
and the systems developers’ modelling intentions are directly expressed by maps. 
This is carefully described in [24] and [25]. 

The experience gained during our previous work shows that the path to be fol- 
lowed in the map during a particular enterprise modelling project is situation- 
dependent. For instance, the selection of the bottom-up 4 path for one of the two end- 
users in the ELEKTRA project was influenced by the uncertainty regarding both the 
current Electricity Distribution Business Unit situation and its possible re- 
organisation alternatives. The application of the specific strategies forming this path 
was also affected by a number of situational factors including: (i) organisational 
culture; (ii) ability to commit resources; (iii) social skills and consensus attitudes of 
participating actors; (iv) use of software tools to facilitate the process execution; and 
(v) familiarity with applied strategies and supporting technologies. 



By opposition, for the second end-user a different path of the map, called top- 
down, was used. The map sections composing this path use mainly the participative 
modelling strategy. For this end-user, the future enterprise goal structure was first 
elicited and then future enterprise process models were conceptualised. 

The EKD-CMM Process Model is shown in Figure 2 as a roadmap. Guidelines 
help users to choose between two alternative sections between a source process inten- 
tion and a target process intention (strategy selection guidelines) or to choose be- 



4 So called because this part suggests first to conceptualize the current enterprise process 
model, then to elicit the current enterprise goal structure and finally to model alternative 
change scenario. 




Participative goal 
modeling deployment 



ICT driven strategy 



Fig. 2. EKD-CMM Roadmap 
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tween possible target intentions when moving from a source intention (intention se- 
lection guidelines). This will be described in Section 4. The execution of each map 
section is also supported by a guideline. 

Some map sections can be defined as maps in a lower level of abstraction. For in- 
stance, the global map section <Start, Conceptualise enterprise process model , Ana- 
lyst Driven Strategy> is defined as a local map shown in Figure 3. This means that 
the method knowledge embodied in the guideline supporting the execution of this 
map section is too complex and too rich to be described in operational terms and 
requires an intermediary intentional description in a lower level of abstraction. 

All guidelines corresponding to the sections between the process intentions Elicit 
Enterprise Goal Structure and Conceptualise Enterprise Business Process Model 
have been developed in [18] and [24]. Our current work consists in identifying and 
developing the methodological guidelines associated to the map sections having the 
process intention Conceptualise Information System Model as source or as target. For 
instance, Figure 4 shows the local map defined to provide guidance to the global map 
section (see Figure 2) <Conceptualise Enterprise Business Process Model, Conceptu- 
alise Information System Model, IS design strategyx The next sections concentrate in 
developing guidance (using local maps) for passing from the Business Process layer 
to the IS layer. 



v&\ 

strate 




strategy 



Fig. 3. Roadmap for conceptualising a business process model from scratch 



3 The Information Systems Architecture (ISA) 



The Information System Model contains not only the representation of the set of IS, 
but also the definition of the local and shared databases, as well as the information 
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requirements and management indicators that should be satisfied by applications 
or IS. 

As we explained before, the main goal of the IS architecture (ISA) is to support 
business processes at the operational and strategic levels. The definition of informa- 
tion requirements and management performance indicators is directly associated to 
business processes through the Business Objects Model (BOM) shown in Figure 1 . 

As stated in [33], business objects do not only provide a natural way to model the 
enterprise, but also guarantee a close link to the business applications. Considering 
that the BOM constitutes the central link between the business processes and the IS 
that support them, special implementation requirements must be considered when 
designing and distributing the enterprise databases and the software components that 
handle them. In order to complete the business objects model of the Business Process 
layer (BOM), the business rules must be linked to the business objects model built at 
the IS layer. We call the latter technical business objects model (TBOM). Business 
rules are useful for defining (i) the set of operations that should be performed over the 
business objects for satisfying information requirements; (ii) the conditions under 
which these operations should be performed. Business rules set up also what business 
objects attributes may change, and what are their domains of validity, when opera- 
tions are performed. Finally they can set the non-functional requirements (security, 
accuracy, etc.). Consequently, the TBOM constitutes the heart of the ISA. 




An ISA comprises the set of enterprise IS, the connections and dependencies be- 
tween them and the ICT required for their implementation. ICT includes hardware 
(PC, servers, nets, and storage, input/output devises, etc.), software (exploitation, 
support, development, and applications) and finally, methodological (project man- 
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agement, development, change control, maintenance, etc.) and technical (languages, 
modelling tools, etc.) artefacts. Considering the evolving environment where enter- 
prises are immersed nowadays, the ISA may include all or part of these types of IS: 
legacy systems, enterprise resource planning applications (ERP), and new specific 
developments. The data distribution and exploitation is directly associated to each IS 
functionality. For completing the set of concepts associated to the enterprise IS layer, 
we include strategic and operational plans which define what, when and how devel- 
oping, maintaining, integrating, or purchasing the systems contained in the IS archi- 
tecture. 



3.1 Technical Business Objects in the Information Systems Layer 

At the IS layer of the EKD-CMM framework, the technical business objects model 
(TBOM) is defined as a refinement of the BOM, which is a sub-model of the Busi- 
ness Process layer (see Figure 1). The BOM must be refined and expressed according 
to the adopted software engineering techniques. Therefore, we determine two com- 
plementary perspectives for defining the set of business objects of an enterprise. Each 
perspective is associated with an enterprise representation layer: (1) the business 
object model (BOM), built at the business process layer, and (2) the technical busi- 
ness object model (TBOM) built at the IS layer. 

Processes inputs and outputs, as well as business resources involved in activities 
drive the business process perspective. Figure 5 shows the process map associated to 
the BOM definition. This map provides guidance for the map section <Start, Concep- 
tualise business objects sub-model , Object driven strategy> shown in Figure 3. 

Observe that there are many ways of conceptualising business objects involved in 
business process executions. There are two main intentions that can be achieved in a 
non-deterministic manner: Define business objects and Elicit business objects. Each 
intention has a set of achieving strategies that may be chosen according to specific 
modelling situations. For instance, there are three different ways of '‘eliciting business 
objects”, the resource based strategy; the event based strategy, and the activity-based 
strategy. Selecting the activity based strategy means that the business objects will be 
discovered by analysing low level activities of the business processes. Notice that, the 
selection of one of these strategies for achieving the elicit business objects intention 
does not eliminate the possibility of selecting the others (two strategies) for complet- 
ing the knowledge associated to the business objects already elicited. The BOM at the 
business process layer, is expressed in conceptual terms without technical considera- 
tions, thus managers and others enterprise members can easily understand it. 

The IS perspective is technology driven; i.e. technical factors such as formal lan- 
guages, and graphical notations controls the modelling process. Figure 6 shows the 
process map associated to TBOM at the IS layer. This map provides guidance for the 
map section <Start, Conceptualise technical business objects model , Object refine- 
ment strategy> shown in Figure 4. Observe that the intentions associated to TBOM 
construction are different from those depicted at Figure 5: Debug business objects 
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and Build technical business objects model. The associated strategies allow modellers 
to choose complementary ways of building and validating the TBOM. 

Notice that the BOM obtained at the BP layer is here refined (see Figure 6) with 
respect to the software engineering and database concepts and techniques for obtain- 
ing first, the logical data model expressed according to the object oriented paradigm; 
and then, the object implementation model. In order to assure the complete corre- 
spondence between the resulting data model and the business information require- 
ments and rules, the data model must be validated against the business process model 
built at the BP layer. Thus, the possible inconsistencies on business object representa- 
tions can be corrected assuring the correspondence between the two business object 
models. 



iusiness objects 
classification strategy 




Business objects composition 
strategy 



Completeness strategy 

Refinement strategy 

Fig. 5. Conceptualising BOM using the object driven strategy at the BP layer 




Fig. 6. Conceptualising TBOM using the object refinement strategy at the IS layer 
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3.2 The ISA and the BP Needs 

It is not easy to discover what the appropriate ISA for a particular enterprise is. There 
are many factors that must be considered while specifying business objects, informa- 
tion requirements, and business processes and activities. The way an activity or a set 
of activities (a business process) is performed, determines if one or several IS are 
needed. This determines also if the business objects should be shared or not, and 
security, quality and access restrictions that must be included in the IS functionalities. 

Therefore, the relationship between the IS layer and the BP layer goes further than 
the simple business objects model definition (BOM and TBOM). The way a set of IS 
is structured, the definition and distribution of IS responsibilities, is a consequence of 
the way that business processes are performed. Besides, there are many other enter- 
prise factors such as priorities, financial and technical issues, that affect the decision 
of implanting a particular IS structure or another. 



3.3 The BP and the IS Issues More Vulnerable to Changes 

In the context of the work still done, we just considered the technical factors associ- 
ated to the technologies needed for business process execution and for supporting the 
exchange of information between business processes. Besides, we should consider the 
strategic perspective of an enterprise that wish to survive in an evolving environment, 
and then its requirement for a flexible ISA. That way, the changes can be analysed, 
defined and implanted easily and with minimal business and ICT impact. From this 
perspective, the definition of the ISA for a business is based on: 

• Business processes execution dependencies, such as inputs/outputs, support, and 
workflow coordination. 

• Business objects owners and users, thus the set of permitted manipulations can be 
elicited and imposed. 

• Legacy and acquired systems and their integration through an Enterprise Applica- 
tion (EAI) perspective. 

• The kind of technology required for the execution of business processes, as well as 
the standardisation of some related procedures. 

• The ICT available and required (restricted according to business financial possi- 
bilities) in the enterprise. 

Almost all of these subjects concern with BP layer characterisation. Nevertheless, 
the responsibility of implementing an appropriate and flexible support for them be- 
longs to the IS layer. 

At the IS layer, the elements more vulnerable to changes are: business objects 
definition (operations, structure, dependence degree, and owner); IS functionalities 
(requirements, dependence degree, and support technology); ICT use (obsolescence, 
flexibility, versions, security, growth capacity); IS implantation (purchase, ERP, inte- 
gration, performance improvement). 
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At the BP layer, the elements more vulnerable to changes are: process change (re- 
engineering- new way of working, TQM); standardisation requirements (business 
processes, procedures, methodologies); work technologies (basic, new, improved); 
business structure (new, restructured); organisation (actors, roles, workflow). 

For concluding this section, it is important to recall that any of these changes af- 
fects the two other business representation layers (Figure 1) or it may comes from one 
of them. For instance, a reengineering process may be the consequence of a change in 
the organisational politics (goals layer). In that case, this change causes a redefinition 
of a set of business processes, and also a redefinition of the IS that support them. 



4 How to Use the Process Maps 

This section illustrates an example of path for the specification of an IS model 
through the conceptualisation of the enterprise process model. Our purpose is to ex- 
plain how to use the process maps as methodological guidelines. In fact, those maps 
assist business owners, business modellers and IS modellers while specifying busi- 
ness models and IS models. 

Enterprise modelling using EKD-CMM is an intention driven process that resolves 
two issues, namely, (1) how to fulfil the modelling intention according to a strategy 
and (2) how to select the right map section to progress. Because the next intention 
and strategy to achieve it are selected dynamically, guidelines that make available all 
choices open to handle a given situation are of great importance. Maps have associ- 
ated guidelines [27], namely one ‘Intention Selection Guideline’ per node /, except 
for Stop, one ‘Strategy Selection Guideline’ per node pair </.,/> and one ‘Intention 
Achievement Guideline’ per section </.,/, Sy>. Given an intention /., an Intention 
Selection Guideline (ISG), identifies the set of intentions { / } that can be achieved in 
the next step. Given two intentions I., I and a set of possible strategies Syi, Sij 2 ,..Sjj n 
applicable to achieve / , the role of the Strategy Selection Guideline (SSG) is to guide 
the selection of one Syk- Finally, the execution of each section is supported by an IAG 
that provides an operational or an intentional means to fulfil a modelling intention. 
For the former, the IAG provides process knowledge specified by the means of op- 
erational models. For the latter, the IAG is defined as a map in a lower level of ab- 
straction. 

All ISGs and SSGs and also the IAGs providing a methodological knowledge de- 
scribed in an operational level are specified according to the contextual formalism 
developed within the ESPRIT project NATURE [34]. We just recall here that a con- 
text is defined as a pair <{situation), intentions-. The kind of EKD-CMM guidelines 
specified above are organised into hierarchies of contexts of three types, namely 
choice (refinement of contexts), plan (composition of contexts) or executable. More 
details about EKD-CMM guidelines can be found in [14], [24] and [25]. 

Let us suppose that we are performing an enterprise modelling process in the fol- 
lowing situation: the organisational maturity of modelling and the participative in- 
volvement are low and there is no available documentation of the business processes. 
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The ISG associated to the intention Start in the EKD-CMM map shown in Figure 2 
suggests us to choice Conceptualise enterprise process model as next intention and to 
apply the IAG associated to the unique map section between these two intentions. 
This IAG is defined as a map, shown in Figure 3, in a lower level of abstraction. 

The ISG associated to the intention Start in the map shown in Figure 3 provides us 
a choice between three intentions. Let us suppose that the modelling team has a great 
experience with object modelling -and less with activity modelling- and a partial 
documentation of the legacy systems is available. Than the ISG associated to the 
intention Start suggests us to choice Conceptualise business objects sub-model as 
next intention and to apply the IAG associated to the unique map section between 
these two intentions. This IAG is again defined as a map shown in Figure 5. 

Let us suppose that the modelling team has a great experience with event-based 
object modelling techniques, for instance Remora. The ISG associated to the intention 
Start in the map of Figure 5 suggests to choice Elicit business objects as next inten- 
tion, and the SSG associated to the couple <Start, Elicit business objects> suggests to 
select the Event based strategy and to apply the IAG associated the section supporting 
this strategy. To make short, let us suppose that navigation is terminated in the map of 
Figure 5 and the other sub-models of the BP layer are specified successively leading 
thus to end the navigation in the map of Figure 3. The specification of the business 
process model being completed, the EKD-CMM map of Figure 2 suggests us to Con- 
ceptualise information system model using IS design strategy. The IAG associated to 
this map section is again defined intentionally as shown in Figure 4. The map section 
<Start, Conceptualise technical business objects model. Object refinements strategy> 
is, in its turn, defined intentionally as shown in Figure 6. When the navigation is 
terminated in the map of Figure 6, modellers go back on the upper intentional level to 
navigate in the map of Figure 4, and finally in the map of Figure 2. 



5 Conclusions and Future Work 

This paper reports on the use of an intentional framework for modelling enterprise 
knowledge using business models and IS models. A major advantage of the proposed 
approach is the systematic way of dealing with enterprise modelling and organisa- 
tional transformation in terms of knowledge modelling used with a process guidance 
framework. The experience gained during our previous work has substantiated the 
view that, paths of the EKD-CMM maps to be followed in a particular enterprise 
modelling project are very much dependent on the enactment context of the enterprise 
project and a number of situational factors. Including degree of formal hierarchy (few 
vs. many formal levels), decision structure (authoritative vs. management by objec- 
tives), company culture (collectivistic vs. individualistic), degree of distance of power 
(short vs. long), type of market (deregulated vs. regulated), etc. Thus, the EKD-CMM 
framework provides a systematic, nevertheless flexible, way to organise and to guide the 
enterprise modelling processes. 
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The EKD-CMM modelling framework allows us to represent an enterprise from 
interrelated perspectives using a three-layer model. It integrates enterprise objectives, 
processes and systems in a single modelling framework. The more relevant feature of 
our framework is that it makes explicit the link between these three modelling layers. 
The way the three layers model has been structured assures that business processes 
are at the origin of the technical business objects as well as the definitions of informa- 
tion requirements and management performance indicators. In consequence, they will 
be taken into account for the design and distribution of the software components. 

The EKD-CMM requires the domain knowledge to fully understand the organisa- 
tion from its multiple perspectives. Rather than trying to gain huge amounts of 
knowledge, a better solution seems to involve several key persons of the enterprise in 
the modelling process. These persons will provide organisational knowledge or will 
know where it may be found. Simultaneously they will become an important resource 
by gaining knowledge of EKD-CMM, which will be useful if the organisation desires 
to continue working with enterprise analysis and modelling. 

Our framework contributes to define accurate decision making processes inside 
modern organisations, which are highly dependent of ICT. It reinforces also the abil- 
ity of companies, which apply it to adopt a policy of knowledge management. 

Our future work will consist to integrate in the EKD-CMM modelling framework, 
the ability to handle the issues listed in Section 3.3. 
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Abstract. Goal models have been used in Computer Science in order to repre- 
sent software requirements, business objectives and design qualities. In previous 
work we have presented a formal framework for reasoning with goal models, in a 
qualitative or quantitative way, and we have introduced an algorithm for forward 
propagating values through goal models. In this paper we focus on the qualitative 
framework and we propose a technique and an implemented tool for addressing 
two much more challenging problems: (1) find an initial assignment of labels 
to leaf goals which satisfies a desired final status of root goals by upward value 
propagation, while respecting some given constraints; and (2) find an minimum 
cost assignment of labels to leaf goals which satisfies root goals. The paper also 
presents preliminary experimental results on the performance of the tool using the 
goal graph generated by a case study involving the Public Transportation Service 
of Trentino (Italy). 



1 Introduction 

The concept of goal has been used in different areas of Computer Science since the early 
days of the discipline. In AI, problem solving and planning systems have used the notion 
of goal to describe desirable states of the world [9]. For example, a planning system might 
be given the goal on (A, B) and on (B, C) , which describes states where blocks A, 
B, C form a stack. The planning system can then analyze the goal (e.g., by decomposing it 
into two subgoals) and find suitable actions that will satisfy it. More recently, goals have 
been used in Software Engineering to model early requirements [2] and non-functional 
requirements [8] for a software system. For instance, an early requirement for a library 
information system might be "Every book request will eventually be fulfilled", while 
"The new system will be highly reliable" is an example of a non-functional require- 
ment. Goals are also useful for knowledge management systems which focus on strategic 
knowledge, e.g., “Increase profits”, or "Become the largest auto manufacturer in 
North America" [5]. Goal-oriented requirements engineering has received consider- 
able attention recently, and is nicely motivated and surveyed in [12] and [11]. Given the 
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criticality of requirements engineering for information system development, the formal 
representation and analysis of goals has become an important research problem to be 
addressed by the CAiSE research community. 

Traditional goal analysis consists of decomposing goals into subgoals through 
an AND- or OR-decomposition. If goal G is AND-decomposed (respectively, OR- 
decomposed) into subgoals Gi, G 2 , ■ ■ ■ , G „ , then all (at least one) of the subgoals must 
be satisfied for the goal G to be satisfied. Given a goal model consisting of goals and 
AND/OR relationships among them, and a set of initial labels for some nodes of the 
graph (S for “satisfied”, D for “denied”) there is a simple label propagation algorithm 
that will generate labels for other nodes of the graph 1 10]. The propagation is carried 
out from subgoals towards an And/OR-decomposed. This algorithm can be used to de- 
termine if the root goals of a goal model are satisfied, given an assignment of labels for 
some of the leaf goals. 

Unfortunately, this simple framework for modeling and analyzing goals won’t work 
for many domains where goals can’t be formally defined, and the relationships among 
them can’t be captured by semantically well-defined relations such as AND/OR ones. 
For example, goals such as “Highly reliable system” have no formally defined predicate 
which prescribes their meaning, though one may want to define necessary conditions 
for such a goal to be satisfied. Moreover, such a goal may be related to other goals, 
such as ‘Thoroughly debugged system”, "Thoroughly tested system” in the sense 
that the latter obviously contribute to the satisfaction of the former, but this contribution 
is partial and qualitative. In other words, if the latter goals are satisfied, they certainly 
contribute towards the satisfaction of the former goal, but certainly don’t guarantee it. The 
framework will also not work in situations where there are contradictory contributions 
to a goal. For instance, we may want to allow for multiple decompositions of a goal G 
into sets of subgoals, where some decompositions suggest satisfaction of G while others 
suggest denial. 

The objective of this paper is to present further results on a formal model for goals 
that can cope with qualitative relationships and inconsistencies among goals. In [4] 
we presented an axiomatization of a qualitative and a quantitative model for goals and 
proposed sound and complete algorithms for forward reasoning with such models. In 
particular, given a goal model and labels for some of the goals, our algorithms propagate 
these labels forward, towards root goals. (If the graph contain loops, this is done until 
a hxpoint is reached.) Figure 1 illustrates a simple example of a goal graph. The figure 
shows a single root goal “Protect users” that might associated with a public transit 
system, AND/OR decomposed several times. The figure also includes some positive 
qualitative contributions, e.g., “Protect driver health” contributes positively (“+” label) 
to the goal “Ensure driver capabilities”. The algorithm proposed in [4] takes as input 
labels for some of the lower goals of the model and infers other labels higher up. This 
is accomplished through propagations from the AND/OR subgoals of a goal to the 
goal itself, also propagations in the forward direction for qualitative relationships. It is 
important to note that this algorithm supports forward reasoning only and requires no 
search. 

This paper uses the same formal setting as [4], but addresses a different set of prob- 
lems. In particular, now we want to know if there is a label assignment for leaf nodes of a 
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goal graph that satisfies/denies all root goals. Assuming that the satisfaction/deniability 
of every leaf goal may require some unit cost, we have also addressed the problem of 
finding a minimum cost label assignment to leaf goals that satisfies/denies all root goals 
of a goal graph. Both problems are solved by reducing them to the satisfiability (SAT) 
and minimum-cost satisfiability (minimum-cost SAT) problems for Boolean formulas. 

The rest of the paper is structured as follows. Section 2 introduces the formal frame- 
work of [4], including a definition of goal graphs and the axiomatization proposed for 
qualitative goal models. The section also reviews SAT and minimum-cost SAT. Sec- 
tion! 3 defines the problem of (simple or minimum-cost) goal satisfiability for a goal 
graph, and shows how it can be reduced to a (simple and minimum-cost) SAT prob- 
lem. Section 4 presents two tools named respectively Goalsolve and GOALMINSOLVE 
that solve either goal satisfiability problem. In section 5 we present experimental re- 
sults on the performance of these tools using the goal graph generated by a case study 
involving the Public Transportation Service of Trentino (Italy). 



2 Preliminaries 

In this section we recall some preliminary notions which are necessary for a full com- 
prehension of the paper. In Sections 2. 1 and 2.2 we recall from [4] and extend a little the 
notions of goal graphs and the axiomatic representation of goal relations. In Section 2.3 
we recall some basic notions about boolean satisfiability and minimum-weight boolean 
satisfiability. 

2.1 Goal Graphs 

As in [4], we consider sets of goal nodes G; and of relations (Gi, ..., G„) i— G over 
them, including the (n + l)-ary relations and , or and the binary relations +5, — s, +d, 

—£>, ++s, Si ++n, d, +1 —1 ++, ■ We briefly recall the intuitive meaning 

of these relations: G 2 ' — > G 1 [resp. G 2 ' — - G 1 ] means that if Gi is satisfied, then there 
is some [resp. a full] evidence that G\ is satisfied, but if G 2 is denied, then nothing is said 
about the denial of Gi ; G 2 ' — G± [resp. G 2 ' — * G\] means that if G 2 is satisfied, then 
there is some [resp. a full] evidence that G± is denied, but if G 2 is denied, then nothing 
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is said about the satisfaction of G' i . The meaning of +d, ~d, ++ d, d is dual w.r.t. 

+S, — s, ++5, s respectively. (By “dual” we mean that we invert satisfiability with 

deniability.) The relations +, — , ++, are such that each G 2 G\ is a shorthand 

for the combination of the two corresponding relationships G 2 G\ andG 2 t— Gi. 
(We call the first kind of relations symmetric and the latter two asymmetric .) 

If (Gi, G„) 1 — > G is a goal relation we call Gj ...G n the source goals and G the 
target goal of r, and we say that ?’is an incoming relation for G and an outcoming relation 
for Gi,...,G„. We call boolean relations the and and or relations, partial contribution 
relations the + and — relations and their asymmetric versions ,full contribution relations 

++ and relations and their asymmetric versions. We call a root goal any goal with 

an incoming boolean relation and no outcoming ones, we call a leaf goal any goal with 
no incoming boolean relations. 

We call a goal graph a pair (Q, TZ) where Q is a set of goal nodes and TZ is a set of 
goal relations, subject to the following restrictions: 

- each goal has at most one incoming boolean relation; 

- every loop contains at least one non-boolean relation arc. 

In practice, a goal graph can be seen as a set of and/or trees whose nodes are connected 
by contribution relations arcs. Root goals are roots of and/or trees, whilst leaf goals 
either are leaves or nodes which are not part of them. 



2.2 Axiomatization of Goal Relationships 

Let Gi,G 2 , ... denote goal labels. We introduce four distinct predicates over goals, 
FS(G), FD(G) and PS(G), PD(G), meaning respectively that there is (at least) full 
evidence that goal G is satisfied and that G is denied, and that there is at least partial 
evidence that G is satisfied and that G is denied. We also use the proposition T to 
represent the (trivially true) statement that there is at least null evidence that the goal 
G is satisfied (or denied). Notice that the predicates state that there is at least a given 
level of evidence, because in a goal graph there may be multiple sources of evidence for 
the satisfaction/denial of a goal. We introduce a total order FS(G) > PS(G) > T and 
FD(G ) > PD(G ) > T, with the intended meaning that x > y if and only if x — > y. 
We call FS, PS, FD and PD the possible values for a goal. 

We want to allow the deduction of positive ground assertions of type FS(G),FD(G), 
PS(G) and PD(G) over the goal constants of a goal graph. We refer to externally 
provided assertions as initial conditions. To formalize the propagation of satisfiability 
and deniability evidence through a goal graph ((? , 72.) , we introduce the axioms described 
in Figure 2. 

( 1 ) state that full satisfiability and deniability imply partial satisfiability and denia- 
bility respectively. For an AND relation, (2) show that the full and partial satisfiability 
of the target node require respectively the full and partial satisfiability of all the source 
nodes; for a “+s” relation, (4) show that only the partial satisfiability (but not the full 
satisfiability) propagates through a “+s” relation. Thus, an AND relation propagates the 
minimum satisfiability value (and the maximum deniability one), while a “+ 5 ” relation 
propagates at most a partial satisfiability value. 
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Goal 


Invariant Axioms 




G : 


FS(G) -► PS{G), FD(G) -► PD(G) 


(1) 


Goal relation 


Relation Axioms 




,G„) n G : 


(A FS ( G >)) - FS(G), (A PS(Gi)) - PS(G) 


(2) 




A (FD(Gi) - FD(G)), f\{PD(Gi) - PD(G )) 

i i 


(3) 


G 2 ^ Gi : 


PS(G 2 ) -► PS(Gi) 


(4) 


G 2 Gi : 


PS(G 2 ) PD(Gi) 


(5) 


/~t 

1 * (jrl . 


FS(G 2 ) FS(Gi), PS(G 2 ) PS'(Gi) 


(6) 


G 2 ^ Gi : 


FS(G 2 ) -* FD(Gi), PS(G 2 ) PD(Gi) 


(7) 



Fig. 2. Ground axioms for the invariants and the propagation rules in the qualitative reasoning 

framework. The (or), (+£>), (—£>), (++d)> ( d) cases are dual w.r.t. (and), (+s), (—5), 

(++s), ( s) respectively. 



Let A : (A"=i v i ) v be a generic relation axiom for the relation r. We call the 
values Vi the prerequisites values and v the consequence value of axiom A, and we say 
that the values Vi are the prerequisites for v through r and that v is the consequence of 
the values u, through r. 

We say that an atomic proposition of the form FS(G), FD(G), PS{G) and PD{G) 
holds if either it is an initial condition or it can be deduced via modus ponens from the 
initial conditions and the ground axioms of Figure 2. We assume conventionally that 
T always holds. Notice that all the formulas in our framework are propositional Horn 
clauses, so that deciding if a ground assertion holds not only is decidable, but also it can 
be decided in polynomial time. 

We say that there is a weak conflict if ( PS{G ) A PD[G)) holds, a medium conflict 
if either (FS(G) A PD(G)) or (PS(G) A FD(G)) hold, & strong conflict if (FS(G) A 
FD(G)) holds, for some goal G. 

2.3 SAT and Minimum-Cost SAT 

Propositional satisfiability (SAT) is the problem of determining whether a boolean for- 
mula <P admits at least one satisfying truth assignment p to its variables A,;. In a broad 
sense, a SAT solver is any procedure that is able to decide such a problem. SAT is an 
NP-complete problem [1], so that we can reasonably assume that there does not exist 
any polynomial algorithm able to solve it. 

In the last years we have witnessed an impressive advance in the efficiency of SAT 
techniques, which has brought large previously intractable problems at the reach of 
state-of-the-art solvers (see [13] for an overview). 

The most popular SAT algorithm is DPLL [3], in its many variants, and Chaff [7] is 
probably the most efficient DPLL implementation available. In its basic version, DPLL 
tries to find a satisfying assignment recursively by assigning, at each step, a value to a 
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proposition. The input formula must be previously reduced in conjunctive normal form 
(CNF) 1 . At each step, if there exists a unit clause, DPLL assigns it to true; otherwise, 
it chooses a literal l and it tries to find an assignment with l set to true; if it doesn’t 
success, it tries with l set to false. In this way, DPLL performs the deterministic choices 
first while postponing, as far as possible the branching step, which is the main source 
of exponential blow up. There are several techniques to improve the efficiency of DPLL 
such as, e.g., backjumping, learning, random restart (again, see [13] for an overview). 

A noteworthy variant of SAT is Minimum- Weight Propositional Satisfiability (MW- 
SAT from now on) [6], The boolean variables A, occurring in 4> are given a positive 
integer weight Wi, and MW-SAT is the problem of determining a truth assignment // 
satisfying <P which minimizes the value 

■■= £< u’i | Ai is assigned T by p}, (8) 

i 

or stating there is none. In the general case MW-SAT is A^-complete problem 2 [6], 
that is, it is much harder than simple SAT. The state-of-the-art solver for MW-SAT is 
MlNWElGHT [6], which is based on a variant of the DPLL procedure. 

3 Goal Satisfiability for Goal Graphs 

In [4] we focused on the problem of the forward propagation of goal values and of the 
detection of conflicts. Given a goal graph, the user assigns some initial values to some 
goals, input goals from now on (typically leaf goals), then these values are forward 
propagated to all other goals according to the rules described in Section 2. As the goal 
graph may be cyclic, the process stops when a fixpoint is reached. The user then can 
look the final values of the goals of interest, target goals from now on (typically root 
goals), and reveal possible conflicts. The whole algorithm is linear in time as it requires 
no form of search. 

In this paper instead we focus on the backward search of the possible input values 
leading to some desired final value, under desired constraints. The user sets the desired 
final values of the target goals, and the system looks for possible initial assignments 
to the input goals which would cause the desired final values of the target goals by 
forward propagation. The user may also add some desired constraints, and decide to 
avoid strong/medium/weak conflicts. 

3.1 Input and Target Goals 

The notions of “input goal’’ and “target goal’’ deserve some more comment. Goal graphs 
may contain cycles, so that, in principle, it is not obvious a priori which goals are target 
goals and which are input ones. Although in our experience the boolean relations tend to 

1 A boolean formula is in CNF if and only if it is in the form /\ . \/ lj t , lj i being literals. A 
disjunction \j . lj i is called clause. A one-literal clause is called unit clause. 

2 Broadly speaking, Af is the class of problems requiring a polynomial amounts of calls to a 
procedure solving an NP problem. 




26 



Roberto Sebastiani, Paolo Giorgini, and John Mylopoulos 




Fig. 3. The simple goal graph of Example 1 . 



FS(G) -> 



/ h f-'S(Gi) V 
V<FS(Ci) V 
FS(Ci) V 
V FD(Ch) 



ir(C?i,-.,(Ti,...C?n)i^— » G 

For every /?,: O’,- £-4 C 
For every Re G, i — ? G 



PS(G) -s- 



( A; PS(G„) V 
Vi«(G,) V 
PS(G:) V 
/T>(G,) V 
PS(Gi) V 



[f (G\,...,Gj,...(i n ) *— A G 
For every Re Gj i — ) G 
For every G, I — 4 G 
For every /?, : G, t— G 
For every Re G, >-24 G 
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++D (II) 
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\ FS(Gi) For eveiy R. : G. ^ G 



PD(G )->• 



/V,fO(G,) V 


A, Pn(Gj) v 


PD(Gl) 


V 


PS(G,) 


V 


P'KGi) 

\PS(G,) 


V 



I f C? 

If •••{?«) •— 4 (j 

For every /?, : G, G 

For every R, : G, G 

For every tf,-: G, h^- 4 G 
for every /?,: G f •— G 



Fig. 4. Axioms for backward propagation (G are non-input goals). 



have a dominant role, so that target goals are typically roots and input goals are typically 
leaves, the choice is typically left to the user. Nevertheless, the choice is not completely 
free, as we impose that every path incoming in a target goal must be originated in an 
input node, that is: 

for every target goal G there exists a direct acyclic subgraph (9) 

(DAG) rooted in G whose leaves G ?1 , ..., Gi k are input nodes, 

so that the value of G derives by forward propagation from those of G^ , ..., G tk . An 
easy-to-verify sufficient condition for (9) is that 

all leaf goals are input goals 3 . ( 10 ) 

Example 1. Consider the simple goal graph of Figure 3, and suppose that Go is the target 
goal and G 2 and G 3 are the input goals. (Notice that Go and Gi form a loop without 
input goals.) If we assigned a final value A’, S' (Go), then by backward search we could 
have FS(Gi) and then FS(Go) again. Thus, FS(Go) could be derived by forward 
propagation from itself without any input value, which is a nonsense. If instead G± is 
an input goal, then by backward search we obtain FS(G 1 ) or FS(G 2 ) and FS(Gs), 
which are suitable initial assignments to the input goals. Notice that (G2, G3) ^4 Go 
and Gi 1 — » Go form a DAG rooted in Go whose leaves are input nodes. O 



3.2 Basic Formalization 

We want to reduce the problem of backward search for input values to that of the 
satisfiability (SAT) of a boolean formula 'P. The boolean variables of ( P are all the 

3 Recall that, by definition of goal graph, every loop contains at least one leaf goal. 
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values FS(G), PS(G), FD(G), PD(G) for every goal G G Q, and <P is written in the 
form: 



& • — ^ graph A d? outval A d? backward [ A ^ constraints A conflict ]> (13) 

where the conjuncts <P grap h , $ outval, & backward, are explained below and the optional 
components <P constraints , and conflict will be described in Section 3.4. 



Encoding the Goal Graph: <P grap h ■ The first component is the representation 

of the goal graph given in the form: 

$ graph ■= /\ Ge g Invar. Ax{G) A Are77 Rel-Ax{r), (14) 

Invar -Ax(G) being the conjunction of the invariant axioms ( 1) for the goal G in Figure 2 
and Rel-Ax(r) being the conjunction of the relation axioms in (2)-(7) and their dual 
ones corresponding to the relation r. These axioms encode the forward propagation of 
values through the relation arcs in the goal graph. 



Representing Desired Final Output Values: <& ou tvai- The second component I* outval 
is a representation of the output values the user want to be assigned to the target goal. 
$ outval is written in the form: 

& outval '■= /\GGTarget.(g) VS (G) A /\G£Target.(g) v d(G) (15) 

Target(G ) being the set of target goals in Q and vs(G) € {T , PS(G), FS(G)}, 
vd(G) € {T, PD(G), FD[G)} being the maximum satisfiability and deniability val- 
ues assigned by the user to the target goal G. I>outvai is a conjunction of unit clauses, 
which force the desired output values vs(G) and vd(G) to be assigned to T. 



Encoding Backward Reasoning: # backward ■ The third component backward en- 
codes the backward search. ^ backward is written in the form: 

^ backward := A G £ g / Input {g ) A v(G) B ac kward.Ax(v(G)) (16) 

Backward.Ax(v(G)) := v(G) -> \J reIncorning ( G ) Prereqs(v(G), r) (17) 

Input(Q) being the set of input goals in Q , Incoming{G) being the set of relations 
incoming in G, v(G) e {PS(G), FS(G), PD(G), FD(G)}, and Prereqs(v(G),r) is 
a formula which is true if and only if the prerequisites of v(G) through r hold. The list of 
possible backward propagation axioms Backward.Ax(v(G)) is reported in Figure 4, 

(11M12). 

Suppose G is not an input goal. If v(G) holds, then this value must derive from 
the prerequisite values of some of the incoming relations of G. Prereqs(v(G), r ) are 
exactly the conditions which must be verified to apply the corresponding relation axioms 
(2)-(7) and their dual ones in Figure 2. 
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3.3 Correctness and Completeness 

The following theorem states the correctness and completeness of the approach. 

Theorem 1. Let (Q, 1Z) be a goal graph. Let Gn , £ Q be the input goals ver- 
ifying condition (9). Let Gf\...Gf n £ Q be the target goals which are assigned the 
values vs(Gfi), vd(Gf\), ... vs(Gf n ), vd(Gf n ) respectively. Let vs{Gn), vd(Gn), ... 
vs(Gik),vd(Gik) be a set of values for the input goals. 

Then vs(Gfi), vd(Gf\), ... vs(G f n ),vd(G /„) can be inferred from vs(Gn), 
vd(Gn), ... vs(Gik),vd(Gik) by means of axioms (l)-(7) if and only if there exists a 
truth value assignment p satisfying (l)-(7), (11)-(12) and the values vs(Gn), vd(Gn), 
... vs(G ik ) and vs(Gfi), vd(Gfi), ..., vs(Gf n ), vd(Gf n ). 

Proof. If: Assume p satisfies vs(Gn), vd(Gn), ... ,vs(Gik ) ,vd(Gik) and vs(Gf i), 
vd(Gf i), vs(Gf n ), vd(Gf n ) and all axioms (l)-(7) and (11 )-( 12). By condition 

(9), for every target goal G there exists a DAG rooted in G whose leaves are all 
input nodes. We reason on induction of the depth of this DAG. If G is also an input 
goal, then G = Gik for some k, so that v(G) is inferred from v(Gik ) by a zero-step 
inference. If G is not an input goal, then there is one backward propagation axiom 
A in (1 1)-( 12) in the form (17) which is satisfied by p. As p satisfies v(G), p 
satisfies source(v(G) , r) for some r. Thus v(G) can be inferred from source(v(G) , r) 
by applying axioms (l)-(7). By induction, source{v(G),r ) can be inferred from 
vs(Gn), vd(Gn), ... vs(Gik),vd(Gik) by means of axioms (l)-(7). Therefore v(G) 
can be inferred from us(G,i), vd(Gn), ... vs(Gik),vd(Gik) by means of axioms (l)-(7). 

Only if: from the hypothesis, us(G/i), vd(Gf i), ... vs(Gf n ),vd(Gik) are inferred from 
vs(Gn), vd(Gn), ... vs(Gik),vd(Gik) by means of axioms (l)-(7). Considerthe assign- 
ment p which assigns T to all the values which can be inferred from vs(Gn), vd(Gn), 
... us(Gjfc), vd(Gik) by means of axioms (l)-(7) and which assigns _L to all other val- 
ues. By construction p satisfies us(Ga), vd(Ga), ... vs(Gik), vd(Gik ) and vs(Gf i), 
vd(Gf i), ... vs(Gf n ), vd(Gf n ), and the axioms (l)-(7). Now let A be a generic instance 
of a backward axiom in (1 1 )-( 12), and let v ( G) be the atom occurring on the left side 
of A, before the G is not an input goal. If p assigns v(G) to _L, then trivially p 
satisfies A. If p assigns v(G) to T, then, by construction of p , v(G) is inferred by means 
of axioms (l)-(7) from some prerequisite values which are assigned T by p. Thus, at 
least one of the disjuncts on the left part of A are satisfied by / / , so that p satisfies A. 
Therefore, p satisfies all the backward propagation axioms (1 1)-(12). Q.E.D. 

3.4 Optional Components 

We describe here the optional components & constraints and ^ con /tict in (13). They allow 
the user to impose some constraints on the possible values of the goals or to force some 
desired value(s). 

Adding User’s Constraints and Desiderata. The first optional component <L> constraints 
allows the user to express constraint and desiderata on goal values. L> constraints is gener- 
ically written in the form: 

d^out.val • — /\^ Vj i 



( 18 ) 
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litij G { PS(G),FS{G ), PD(G), FD(G), -.PS(G), ->FS(G), ~^PD{G) 1 ~^FD{G)}, 

G € Q. A positive unit clause value is used to impose a minimum value to a goal. (E.g., 
“PS(G i)” means “G 1 is at least partially satisfiable”, but it might be totally satisfiable.) 
A negative unit clause value is used to prevent a value to a goal. (E.g., “->FD(Gi)” means 
“Gi cannot be fully deniable”, but it might be partially deniable.) A disjunction of positive 
values is used to state an alternative desideratum. (E.g., “FS(G i) V FS(G 2 )” means 
“at least one between Gi and G 2 must be fully satisfiable”.) A disjunction of negative 
values is used to state a mutual exclusion constraint. (E.g., “FD[G 1 ) V FD(G 2 )" means 
“Gi and G 2 cannot be both fully deniable”, but they can be partially deniable.) 



Preventing Conflicts. The second optional component conflict allows the user for 
looking for solutions which do not involve conflicts. Depending whether one wants to 
avoid (i) only the strong conflicts, (ii) the strong and medium conflicts or (iii) all conflicts, 
d> conflict is encoded respectively as follows: 

Conflict ~ A Ge ghFS(G) V -nFD(G)) (19) 

$ conflict '■= A Ge g(h FS ( G ) V -<PD(G)) A (-> PS(G ) V ->FD(G))) (20) 

conflict ■= A Ge gh p S(G) V -PD(G)). (21) 

(19) states that G cannot be fully satisfiable and fully deniable; (20) states that G cannot 
be fully satisfiable and (fully or) partially deniable, and vice versa; (21) states that G 
cannot be (fully or) partially satisfiable and (fully or) partially deniable. Notice that, by 
Axioms (1 ), (21) implies (20) and that (20) implies (19). 

It is easy to see that Theorem 1 extends straightforwardly to the case when we have 

$ constraint and $ conflict components. 

4 Solving Simple and Minimum-Cost Goal Satisfiability 

Consider a goal graph (Q, 1Z) with input goals Gi 1 , ..., Gik and target goals G/i, G/ n , 
and a set of desired final values vs(Gf 1 ), vd(Gf 1 ), ... vs(Gf n ), vd(Gf n ) to the target 
goals (plus possibly a set of user constraints and desiderata), and let <1> be the formula 
encoding the problem, as in (13). 

Theorem 1 states that (i) if <!> is unsatisfiable, then no value exists to the input 
goals from which the desired final values derive by forward propagation (verifying the 
desiderata and constraints) (ii) if an assignment /i satisfying <1? exists, then the maximum 
values vs(Gn), vd(Gn), ... vs(Gi n ), vd(Gik) which /i assigns to T are such that the 
desired final values derive from them by forward propagation (verifying the desiderata 
and constraints). This allows for reducing the problem of backward search to that of 
propositional satisfiability. 

4.1 Goalsolve 

We have implemented a tool, called GOALSOLVE, for the backward search of the possible 
input values leading to some desired final value, under desired constraints. The schema 




30 



Roberto Sebastiani, Paolo Giorgini, and John Mylopoulos 



I Graph I 

• Final Values . 
1 [Des. & Constr. 1 ] 

I [Input Goals] ' 

I I Flags] I 

,[We?ghts]_ _ , 



Goal Values 



* 

* 







1 






Encoder 


* Formula <]) * , 


SAT Solvei 






( ivar. w eights j 1 t 


(Chaff) 




W 




I Table 


A \ 






m L 








a 1 SAT/UNSAT I aJ ^ 


Weight 




Decoder 


1 [Assignment |T) UR 


SAT Solver 






1 1 


(Minweight 



Fig. 5. Schema of GOALSOLVE (black arrows) and GOALMINSOLVE (gray arrows). 



of GOALSOLVE is reported in Figure 5 (black arrows). GOALSOLVE takes as input a 
representation the goal graph, a list of desired final values and, optionally, a list of user 
desiderata and constraint and a list of goals which have to be considered as input. (The 
default choice is that indicated in condition (10), that is, all leaf goals are considered 
input goals.) The user may also activate some flags for switching on the various levels 
of “avoiding conflicts’’. 

The first component of GOALSOLVE is an encoder that generates the boolean CNF 
formula 4> as described in Section 3, plus a correspondence table Table between goal 
values and their correspondent boolean variable. 4> is given as input to the SAT solver 
Chaff [7] , which returns either “UNSAT” if 4> is unsatisfiable, or “SAT” plus a satisfying 
assignment /x if tP is satisfiable. Then a decoder uses Tab 1 e to decode back the resulting 
assignment into the set of goal values. 

4.2 GOALMINSOLVE 

In general, the satisfaction/deniability value of (input) goals may have different costs. 
Thus we have implemented a variant of GOALSOLVE, called GOALMINSOLVE, for the 
search of the goal values of minimum cost. The schema of GOALMINSOLVE is reported 
in Figure 5 (gray arrows). 

Unlike Goalsolve, Goalminsolve takes as input also a list of integer weights 
W{val{G)) for the goal values. (The default choice is W(FS(G)) = ( FD(G )) = 2 
and W(PS(G)) = ( PD(G )) = 1 if G is an input goal, W(FS(G)) = ( FD(G )) = 
W(PS(G)) = ( PD(G )) = 0 otherwise.) The encoder here encodes also the input 
weight list into a list of weights for the corresponding boolean variables of 4>. Both 4> 
and the list of weights are given as input to the minimum-weight SAT solver MlNWElGHT 
[6], which returns either “UNSAT” if 4> is unsatisfiable, or “SAT’ plus a minimum-weight 
satisfying assignment /j if 4> is satisfiable. The decoder then works as in GOALSOLVE. 

Notice that, in general, there may be plenty many satisfying assignments - up to 
exponentially many - corresponding so solutions for the problem. In a typical session 
with Goalsolve or Goalminsolve, the user may want to work first with the “avoiding 
conflicts” flags, starting from the most restrictive (21) down to the least restrictive (19), 
until the problem admits solution. (E.g., it often the case that no solution avoiding all 
conflicts exists, but if one allows for weak and/or medium conflicts a solution exists.) 
Then, once the level of conflict avoidance is fixed, the user may want to work on re- 
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fining the solution obtained, by iteratively adding positive and negative values - e.g. 
“->FD(G'i)”, “ FS(G 2 )” - in the list of desiderata and constraints, until a satisfactory 
solution is found. 

5 A Case Study 

We consider as a case study the strategic objectives for the Public Transportation Service 
of the region of Trentino (Italy), we have recently analyzed for the CitiMan (Citizen 
Mobility Modeling and Management) project in collaboration with Centro Ricerche 
FIAT. As depicted in Figure 6, the main objective of the Trentino government is supply 
public transport service to the citizens, involving satisfy users, minimize costs per 
user, improve the quality of life, and protect users 4 . 

The objectives are further analyzed and refined using AND/OR decompositions. For 
instance, supply public transport service to Trentino citizen is AND-decomposed in 
guarantee transportation, sell tickets and manage financial budget. In turn sell 
tickets is AND-decomposed into decide sale strategy, decide sales strategy and 
avoid frauds, while the goal manage financial budget is AND-decomposed into ob- 
tain founds, manage services’ costs and manage profits. Likewise, improve trans- 
portation services is OR-decomposed into improve old services and supply new 
services, while protect users is AND-decomposed in guarantee drivers capabili- 
ties, guarantee the user behavior, and protect user health. 

The graph shows also lateral relationships among goals. For example, the goal pro- 
tect user health has positive + contribution from the goal monitor pollution, while the 
goal minimize cost per user has two negative — contributions from goals provide com- 
fort and improve transportation services. Asymmetric relationships are also showed; 
for instance, the goal satisfy users has a ++ n contribution from protect user and 
guarantee transportation, and a +s contribution from improve quality of life and 
again guarantee transportation. 

We run a series of experiments with GOALSOLVE and GOALMINSOLVE on the goal 
graph in Figure 6. Both GOALSOLVE and GOALMINSOLVE have been implemented in 
C++ and the tests were conducted on a Dell Inspiron 8100 laptop with a Pentium III 
CPU and 64 MB RAM (OS: GNU/Linux, kernel 2.4.7-10). The tests were intended to 
demonstrate the practical effectiveness and benefits our approach, and also to check the 
efficiency of the tools. As for the latter aspect, in all our experiments both GOALSOLVE 
and GOALMINSOLVE performed in less than one second. (Of course, such performances 
depend on the goal model and the desiderata we want to obtain.) To provide examples, 
we briefly describe a few of these experiments. (We report here only the results for 
GOALMINSOLVE, which are more interesting.) 

In a first set of experiments we imposed supply public transport services as target 
goal and all the leaves nodes except satisfy users and minimize cost per user as 
input goals, having as a desideratum the full satisfiability of the target goal. We run 
GOALMINSOLVE with the default settings for the weights. 

Imposing the strongest conflict avoidance conditions (21) or (20), GOALMINSOLVE 
discovered there were no solution, whilst imposing the weakest condition ( 19) Goalmin- 

4 The goal names are translated from Italian. 
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Table 1 . Results of the first and the third set of experiments. (We omit the values of non-input 
goals and of those input goals which were not assigned any value.). 
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SOLVE found the results shown in Table 1 (Expl ). We notice the presence of conflicting 
values for some top and input goals. In fact, the FS value of supply public transport 
service is backward propagated down to all elements of the and tree rooted there, in- 
cluding invest on the service. This propagates a PS value to provide comfort and 
improve transport services, and hence a PD value to minimize costs per user, sat- 
isfy users, and hence to the target goal supply public transport service, generating 
thus a medium conflict. When we tried to eliminate only this conflict by imposing a ~^PD 
constraint on the target goal, GOALMINSOLVE stated there was no solution anyway. 

Thus, GOALMINSOLVE highlighted the fact that, with the goal graph of Figure 6, the 
full satisfiability of the main target goal cannot be accomplished without generating 
conflicts. 

A second set of experiments showed that it is not possible to obtain the full satisfaction 
for the main goals of the Trentino Public Transportation System, namely supply public 
transport service, satisfy users, improve quality of life, and minimize cost per 
user, even admitting all kinds of conflicts. This is easily explained with the fact that 
both satisfy users and minimize cost per user are non-input and have no boolean, 

++S and £> incoming relations, so that there is no way they can be assigned a FS 

by forward propagation. 

In a third set of experiments we have expressed as desiderata the full satisfaction for 
both goals improve quality of life and protect users, without saying anything about 
the other goal (in particular about the top goal supply public transpiration service). 
Also in this experiment it was not possible to have an assignment without conflicts, 
but we found a solution allowing medium conflicts (option (19)). As shown in Table 1 
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Fig. 6. The goal model for Trentino Public Transportation Service. 
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(Exp3), the assignment to the input goal produces conflicts to the top goals supply public 
transport services, satisfy users and minimize cost per user which, again, cannot 
be avoided. 

A final set of experiments were carried out with graphs with a bigger number of nodes. 
The goal of the experiments was to evaluate the performance of our tool with respect to 
the growth of the dimension of the graphs. We generated such graphs randomly. Starting 
from the model of Figure 6, we generated new graphs adding randomly new goals and 
contribution links between goals, and thereby generating new cycles. Of course, since 
we were only interested on the structure of the graphs, we have not associated to them 
any semantics. 

The results showed that also for bigger graphs (from hundred to two thousand nodes) 
Goalsolve performed in less than one second, whereas GOALMINSOLVE performed 
relatively well (less than five seconds) for graphs with a number of nodes less than three 
hundred. This suggests us that our approach can be applied in real life applications where 
goals models can count more than hundred goals. 

6 Conclusions and Future Work 

This paper introduces the problem of goal (plain/minimum-cost) satisfiability and pro- 
posed a solution by reducing goal satisfiability to the problem of (plain/minimum-cost) 
satisfiability for Boolean formulas. The solution has been implemented and evaluated 
with a case study. As illustrated by the case study, the solution makes it possible to 
answer questions such as “Is there a set of labels for input goals that satisfies all output 
(root) goals?”, and if so, “Which solution is minimum cost?” 

The proposed solution only works for qualitative goal models, where goals can be 
satisfied or denied, possibly partially. We plan to continue this research and extend these 
results so that they also apply to quantitative models, where one can also talk about goals 
being satisfied/denied with an attached probability/cost or other numerical measures. 
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Abstract. Current eCommerce is still mainly characterized by the trad- 
ing of commodity goods. Many industries offer complex compositions 
of goods based on customers’ specifications. This is facilitated by a 
component-based description of goods, supported by a variety of product 
classification schemes, e.g., UNSPSC and eCl@ss. These focus on phys- 
ical goods - wrongly referred to as products - rather than on services. 
Services are intangible products, for instance insurances, transportation, 
network connectivity, events hosting, entertainment or energy supply. 
Due to major differences between goods and services, product classifi- 
cation schemes cannot support automated service scenarios, such as a 
customer who wishes to define and buy a set of independent services, 
possibly supplied by multiple suppliers, via one website. To enable such 
eCommerce scenarios for services, a service ontology is required that sup- 
ports a component-based structure of services. Defining a set of services 
is then reduced to a configuration task, as studied in the knowledge man- 
agement literature. In this paper we use a case study from the Norwegian 
energy sector to describe how a component-based ontological description 
of services facilitates the automated design of a set of services, a so called 
service bundle. 



1 Introduction 

Although some e-business initiatives have failed, the massive diffusion of the 
Internet still opens up many new opportunities for businesses, such as in the 
field of online service provisioning. So far, the Internet has mainly been used 
as a channel for selling physical goods. It is for instance quite common that 
customers can configure a complex good (e.g. a PC) out of more elementary 
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A. Persson and J. Stirna (Eds.): CAiSE 2004, LNCS 3084, pp. 36—50, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 




Energy Services: A Case Study in Real-World Service Configuration 



37 



components and order such a good online. Examples can be found on websites 
of market leaders such as Dell and Cisco. Such an eCommerce scenario requires a 
component-based ontology of goods , specifically suited for classification (to allow 
customers to find goods) and configuration (to facilitate in composing complex 
goods). Examples of such supporting ontologies are UNSPSC [3] and eCl@ss [2]. 

Unlike physical goods, services are not supported well by these ontologies 
due to major differences between services and goods: their intangible nature (vs. 
tangible goods) , customer involvement in the production process of services (vs. 
standard, off the shelf goods), difficulties in ensuring standard quality levels due 
to the important role of employees in the service process, and more [19]. 

However, from an economical perspective, services grow more and more in 
importance [4] , and will be offered and deployed via the Internet increasingly. It 
is therefore important to extend current goods-biased classification and configu- 
ration ontologies with a service perspective. This paper proposes an ontological 
foundation for service configuration. 

It is important to understand that our interpretation of the term service 
stems from business science, a community that has been researching the notion 
of services extensively already for decennia [15, 12, 23, 19, 21, 16, 8]. So, we do not 
take web-services publications such as [22] as our starting point; web-services 
take hardly a commercial/business value perspective on services, a perspective 
that is needed by customers and suppliers to configure valuable, complex services. 

Based on service marketing and service management literature we have cre- 
ated a generic service ontology that describes services both from a supply-driven 
and demand-oriented perspective. We combine our business-driven conceptual- 
ization of the service sector with knowledge management research, specifically 
work on configuration task ontologies [13]. As a result, by using our service ontol- 
ogy as well as already existing configuration ontologies we can configure complex 
services (called a service bundle) out of more elementary services, possibly of- 
fered by multiple suppliers. 

In the remainder of this paper we explain how the service configuration pro- 
cess takes place, and how it is facilitated by a service ontology. We demonstrate 
how we put our theory into practice by presenting a case study from the energy 
sector. We first present in Section 2 a top-level description of our service ontol- 
ogy, followed by an explanation of service terminology that underlies our work 
(Section 3). Subsequently, in Section 4 we explain how services can be described 
as components. Then, in Section 5 we introduce our case study domain, the 
electricity market, and we analyze potential service bundles in this market using 
our configuration-biased service ontology. Finally, in Section 6 we present our 
conclusions. 



2 Service Ontology 

Using the service management and marketing literature as a starting point, 
we have developed in earlier work a generic component-based service ontology 
[7, 6]. The ontology incorporates both a customer perspective and a supplier per- 
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spective on services, and it includes unique characteristics of services (compared 
to goods), e.g., the intangible nature of services. It allows customers to configure 
compound services, based on their specific requirements and expectations. 
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Fig. 1 . Three top-level ontological distinctions to be made in a generic service ontology: 
the customer-value perspective, the supply-side perspective, and the joint operational- 
ization of these viewpoints in terms of the actual service production process 

On a high level of abstraction, a service ontology must embody three inter- 
related top-level perspectives: service value, service offering and service process 
(see Figure 1). The service value perspective describes the service from a cus- 
tomer’s point of view in terms of a customer’s needs and demands, his quality 
descriptors and his acceptable sacrifice, in return for obtaining the service (in- 
cluding price, but also intangible costs such as inconvenience costs and access 
time). The service offering perspective describes a service from a supplier’s per- 
spective; it provides a hierarchy of service components (service elements) and 
outcomes, as they are actually delivered by the service provider in order to sat- 
isfy customers’ needs. The service process perspective describes how the service 
offering is put into operation (the operationalization relation in Figure 1) in 
terms of business processes that can be modeled using existing technologies as 
ebXML [1], WSFL [17] or BPEL [5]. Customers often take active part in the 
service production process (the participation relation in Figure 1). 

Service configuration, or serviguration , is the process of defining sets of ser- 
vice elements (a supply-side description of services, part of the service offering 
perspective), that satisfy the customer description of his desired service ( service 
value perspective). Serviguration can be split into two sub-processes: (1) trans- 
formation process between a customer description of the requested service and 
a supplier terminology for describing the service; and (2) defining zero or more 
sets of service elements that satisfy this supplier description of the requested ser- 
vice^), and thus also the customer description of his requested service(s). This 
paper focuses on the second sub-process of the serviguration process: a task of 
configuring elementary services into a complex service bundle. It is important to 
understand that elements of the service offering perspective - which we model 
- cannot be modeled using business process modeling techniques, as the essence 
of value-oriented models is different from that of business process models. For 
a thorough explanation see [11]. Our work includes also the first sub-process of 
the serviguration process, a mapping task between customer requirements and 
available services. However, due to scope limitations, we do not discuss it in the 
present paper. 
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3 Service Terminology 

In this section, we briefly review the core ontological concepts in our service 
ontology. For a more detailed discussion see [7, 6]. 

Service element represents what a supplier offers to its customers, in sup- 
plier terminology. It is what the business literature defines as service, a business 
activity (performance) of mostly intangible nature. A service element can be a 
composite concept; it can be decomposed to smaller service elements, as long as 
the smaller service elements can be offered to customers separately or by differ- 
ent suppliers. The business science literature discusses the notions core service, 
supporting service and enhancing service. A core service represents the reason 
for the supplier’s presence on the market. For example, the core service of an 
insurance company is providing insurances; the core service of an airline is pro- 
viding transportation. Supporting services are needed in order to enable the 
core service consumption. In the absence of these services, the core service con- 
sumption is no longer possible. For example room cleaning services in hotels. 
Enhancing services are often considered to be the elements of the service that 
define it and make it competitive. They increase the value of the service, or 
differentiate it from those of competitors [12]; the core service can nevertheless 
be consumed without them. An example is providing credit card holders with a 
“free” travel insurance. Neither supporting services nor enhancing services are 
offered independently of a core service. We adopt a customer-oriented definition 
of core service: a core service is not a main service that a supplier sells, but 
rather a main service a customer is interested in. For example, when a customer 
buys an airline ticket with a travel insurance, his core service is transportation, 
rather than insurance. However, from the insurance company’s perspective, the 
travel insurance is a core service, since this is a core activity of that company. 

Resource is either a pre-requisite for the provisioning of some service el- 
ement, or the outcome (result) of a service element. We call resources service 
inputs or service outcomes. A resource may be the outcome of some service ele- 
ment, as well as the input of another service element. Very often the outcomes of 
a service reflect the customer benefits from a service. Resources may be of several 
types: physical goods (sometimes defined as ‘those things that can be dropped 
on the floor’), human resources, monetary resources, information resources (e.g., 
customer information or a weather report service), capability resources (the abil- 
ity to do something, which is of value to some actor, e.g., the ability to connect 
to the Internet 24x7), experience resources (e.g., an added value of going to 
Euro Disney is having fun) and State-change resource. The latter type requires 
an explanation. Services are “activities... of bringing about a desired change in 
or on behalf of - the recipient of the service” [19]. Sometimes the change can 
be related to a property of some resource (e.g., a car’s state changes in a car 
repair service), whereas in other services the subject of the state-change is not 
a resource, e.g., a passenger taking a flight undergoes a state change. In such 
cases the customer value of a service is a change of state: the customer was in 
Amsterdam, and now he is in Sydney. He pays for this change of state. 
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Service bundle is a set of one or more service elements that are offered 
together, possibly by more than one supplier. The service elements need not 
be related to each other; however, there will always be some logic behind the 
decision to bundle services. Services may be bundled because they depend on 
each other, to make better use of existing resources, for marketing goals, because 
legislation requires it and more. 

4 Configuration of Services 

Using the above terminology, we can describe services and service bundles in a 
similar way to how components and configurations are described in the knowl- 
edge systems literature. In particular, configuration is a constructive task, based 
on the availability of a set of predefined components, connections, and associ- 
ated parameters and constraints [20, 18, 13]. We will describe service elements as 
components, so that a configuration process can create service bundles. Our dis- 
cussion can be split into two parts: describing service elements (elementary and 
complex) and describing constraints on connections between service elements. 

4.1 Service Element 

Components, as described in the knowledge engineering literature [13,18,9, 10], 
have ports, constraints and properties. We claim that the component-based na- 
ture is inherent to services. As such, we can identify ports, constraints and 
properties for service elements. 

Ports. Every service element has ports of two types: input ports and outcome 
ports. The provisioning of a service element requires core resources, and results 
in the availability of other resources. A port indicates a certain resource that is 
either a pre-requisite for carrying out this service element (input port), or the 
result of carrying out this service element (outcome port). A service element 
cannot be provisioned if not all required inputs are available; it results in the 
availability of all outcome resources. The set of all input ports, respectively all 
outcome ports of a service element form the element’s input interface, respec- 
tively outcome interface. 

Constraints. We distinguish between constraints that are internal to some ser- 
vice element (e.g., constraints on associated resources) and constraints on the 
relationships between service elements. The latter type is referred to as functions 
(see Section 4.3). 

We can also identify properties of service elements. Some properties are 
generic (e.g., quality, productivity, sacrifice), whereas others are domain-specific. 
We found that all service properties can be described as resource properties as 
well. Hence, the properties of a service are expressed as the properties of its 
associated resources. The concept service element is visualized in Figure 2. 

4.2 Service Bundle 

A service bundle is a complex service element, that includes one or more (possibly 
complex) service elements. Hence, a service bundle has an input interface and 
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Fig. 3. Service bundles 



an outcome interface. The input interface, respectively outcome interface of a 
service bundle, are identical to the union of the input interfaces, respectively 
outcome interfaces, of all service elements included in a service bundle. Two 
deviations from this rule exist: 

(1) when resources have the sharability property, they may be consumed after 
they had already been consumed. For example a pricing model is a static infor- 
mation resource that can be used multiple times and still be available. 

(2) when resources have the compositeness property, multiple resources of the 
same type may be modeled as one resource. For instance, when two service el- 
ements are bundled, and both require a payment input, these two inputs can 
be composed into one payment resource. Very often the price in case of such 
bundling is lower than the sum of both prices. 

The input interface of a service bundle must provide all inputs of all service 
elements that are part of this bundle, unless they are provided internally (one 
service element may produce an outcome that is consumed as an input by a 
different service element). Examples of service bundles are shown in Figure 3. 
Links between ports mean that one port uses a resources that another port 
provides. 

4.3 Functions 

Function is a relationship that defines dependencies between two service ele- 
ments. It represents a constraint on how these service elements may or may not 
be bundled, rather than on the service elements themselves. A function is a for- 
mula that receives two arguments of type ‘service element’ (A - the dependee, 
and B - the dependent) , and produces as output a set of possible configurations 
of these two inputs. We defined the following functions (with A, B as service 
elements) based on business science literature [12, 14, 15, 19] and on case studies: 

1. Core/enhancing (A, B): B is an enhancing service of A (and thus A is a 
core service of B). Hence service A is a main service a customer is interested 
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in, whereas service B: (1) is not required for the provisioning of service A; 
and (2) adds value to A; and (3) is an optional service element, next to A; 
and (4) is not offered independently. If a customer wishes to consume service 
element A, he is presented with the option to consume also B, but he is not 
obliged to consume B. 

Notation: A ~^ en h B 
Output: {A},{A,B} 

2. Core/supporting (A, B): B is a supporting service of A (and thus A is the 
core service of B). In business terms it means that A cannot be provisioned 
without B and that B is not offered independently. Very often B will not 
present value as such for customers (e.g., billing services), but yet it must be 
provided to enable the provisioning of A. If a customer wishes to buy service 
A, he is obliged to consume service B as well. 

Notation: A —y supp B 
Output: {A,B} 

3. Bundled (A, B): If a customer wishes to buy service element A, he is 
obliged to buy also B. This is similar to the Core/ supporting function. How- 
ever, in this case B may be offered independently, and the reason for the 
obligatory consumption of B is different. In the case of bundled services, the 
bundling is required due to some business logic, such as cost efficiency rea- 
sons, marketing reasons, legislation and more. 

Notation: A —>bund B 
Output: {A,B} 

4. OptionalBundle (A, B): Two services A and B are offered separately, 
but also as an optional combination (bundle). In most cases, the bundling 
of two such service elements presents added value to the supplier (e.g., 
lower operational costs) as well as to the customer (lower price). Unlike 
the core/enhancing function, in the optional bundle case service B can also 
be offered independently of service A. 

Notation. A y optBund B 
Output: {A},{A,B} 

5. Substitute (A, B): The benefits presented by A (in terms of service out- 
comes) to a customer are also presented by B (but B possibly offers more 
benefits). B can therefore be bought instead of A; customers can choose 
which one of them they prefer. 

Notation: A — » su bst B 
Output: {A},{B} 

6. Excluding (A, B): If service element A is consumed, service element B 
may not be consumed, for example due to business reasons (A and B are 
competing services, and the supplier does not want to provide them together) 
or legislation that prohibits selling both services together. 

Notation: A -^ exc i B 
Output: {A} 
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5 Case Study: Bundling Electricity Supply 
with Other Services 

5.1 Differentiation of the Electricity Product in Norway 

Electricity becomes more and more a commodity product. Competing suppliers 
are offering electricity to end-customers but the price per kWh is (nearly) the 
same. Additionally, it is delivered according to the same standard and consumed 
through the same electricity socket in a customer’s home. 

As a result, it is for electricity suppliers hard to compete with each other. 
Consequently, many suppliers are seeking for ways to differentiate their product. 
One way to do so is to add complementary and additional services such as 
Internet access and home comfort management. In many cases, suppliers can 
use existing infrastructure and/or available business processes to deploy such 
extra services, so bundling these services can be done with relatively modest 
effort. The study presented in the next sections utilizes and exemplifies our 
service ontology as well as existing work on configuration theory from AI, using 
a project we carried out for an electricity supplier in Trondheim, Norway. First, 
we elicit elementary service elements, their outcomes and inputs, constraints 
and functions. Knowing these elements, we configure bundles of service elements 
and outcomes, in effect various combinations of the outcome ‘electricity’ with 
additional outcomes. 

5.2 Energy Service Elements 

Multiple suppliers offer a variety of services that can be bundled with electricity 
supply in the energy sector. Some of the services are required in order to make 
possible the supply of electricity, while others add value or help suppliers differ- 
entiate themselves in this market. We identify the following service elements: 

— Electricity supply; the selling of electricity to end-consumers. 

— Electricity transmission to end-consumers. The Norwegian law forbids 
electricity supply and transmission to be done by the same company. 

— Heat pump uses electricity for space heating. It provides maintained com- 
fort with less use of electricity. 

— Energy control system enables controlling the temperature and switching 
appliances on/off. It gives the customer the possibility to reduce electricity 
consumption and maintain a comfortable temperature. 

— Broadband (Internet) access is offered in a limited geographic area. 

— Hot water for room heating and tap water requires some technical in- 
frastructure that is available in certain regions only. It provides the same 
functionality as heating water with electricity, but for a lower price. 

— Remote control: web-based control of home appliances. 

— Contracting. Many services require a contracting service element. However, 
the description of most services (in our case study) is quite different from 
that of electricity supply and transmission. Hence, we model three contract- 
ing service elements: electricity supply contracting, electricity transmission 
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contracting, and a generic contracting service element that all other services 
can use. 

— Billing is also a service element that many other services require; it always 
requires some information about the contract, and results in an invoice. We 
model one generic billing service element. 

We identified and modeled more services, e.g., ASP-services, safety check of elec- 
trical installations and more, but we do not discuss them further for the sake of 
brevity. In the remainder of this section we present two detailed examples of how 
service elements can be modeled as components. Figure 4 shows visualizations 
of two more such service elements. 
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Fig. 4. Service elements: electricity supply, energy control system and contracting 



Service Element: Broadband Access 

Broadband Internet access is offered as an independent service (not necessarily 
bundled with electricity supply) . The service is provided in a limited geographic 
region, where the required infrastructure is available. 

Service Inputs: 

Payment. Type: Monetary resource. Compositeness : Formula (when bundling 
two or more services, their payment inputs can be composed into one payment 
resource, based on a pricing- formula of the supplier) . 

Customer Information. Information about the customer, such as type of cus- 
tomer (household or industrial), name and address, postcode (to verify the geo- 
graphic constraint of this service). Type: Information resource. 

Service Outcomes: 

Pricing Model. Type: Information resource. State: The chosen product for 
broadband access. Possible alternatives are basic, regular etc, implying differing 
download/upload speeds. Sharability: Infinite (The pricing model is determined 
in this service element, and then serves as input for the contracting and billing 
service elements. Being a static information resource, it can be consumed an 
infinite number of times) . 
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Broadband Internet. Type: Capability resource. State: Available. Productiv- 
ity: 256/128 kbps (download/upload), 512/128 kbps or 704/256 kbps. Medium: 
wireless OR fiber optics. 

Service Element: Billing 

Billing is a generic supporting service element ; it is required to enable the con- 
sumption of several other service elements. 

Service Inputs: 

Pricing Model: Type: Information resource. State: Defined per service ele- 
ment. 

Customer Information: Data about the consumption for the specified cus- 
tomer. Type: Information resource. 

Service Outcomes: 

Invoice: Type: Monetary resource. Productivity: Frequency of invoices (monthly, 
four times a year, yearly). 

The above description of service elements is a generalization. In reality, when 
we model these service elements, we have multiple broadband access service el- 
ements, multiple electricity supply service elements etc, with varying values for 
the same resource properties. For example, instances of the broadband access 
service element exist with differing quality levels: basic, regular or luxurious. 
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Fig. 5. Constraints on bundling services in the energy sector 



5.3 Functions: Constraints on Service Bundling 

Having modeled service elements in the energy sector, we can now look at de- 
pendencies between service elements. These are formulated in terms of the func- 
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tions presented in Section 4.3. Together with domain experts we created a ma- 
trix of service elements, and every slot in the matrix represents the value of a 
function between two service elements. We use the following abbreviations: CS 
(Core/supporting), OB (Optional bundle), SU (Substitute), BU (Bundled). The 
notation means that there is no function between the two associated service 
elements. This matrix is presented in Figure 5. It has to be read as follows: 
every slot defines a function Function (row, column). In other words, service ele- 
ments in the rows are the first argument of a function, and service elements in a 
column are the second argument of a function. For example: service element elec- 
tricity transmission has an optionalBundle function with electricity supply and 
a core/supporting function with the service elements billing and contract elec- 
tricity transmission. Multiple service elements naturally have a core/supporting 
function with billing and with contracting. Defining the set of functions (see Sec- 
tion 4.3) is a conceptual modeling task, mostly based on existing business science 
research. Instantiating the model as done in Figure 5, on the other hand, is done 
by mapping domain knowledge into the structures of our service ontology. 

5.4 Configuring Service Bundles in the Electricity Market 

A main reason behind our study of service bundles in the energy sector is to 
develop offerings so that our case study partner can differentiate herself from 
competitors. The same methodology can also be used to offer customers the 
possibility to define a set of services that they are interested in. In this section 
we analyze how services can be bundled in a scenario in which a customer is 
interested in electricity, as well as in broadband Internet. Similar scenarios can 
be created for any of the other service elements we modeled. 

The input for the configuration process includes three parts: 

1. A set of all available service elements, including their associated resources. 

2. A set of all functions between any pair of service elements (see Figure 5). 

3. A set of initial requirements. In our scenario we require the service outcomes 
electricity and broadband Internet. Deriving these requirements, based on 
a modeling of customer requirements, is facilitated by a mapping between 
concepts of two perspectives in our ontology: the service value perspective 
and the service offering perspective. As mentioned before, this process is not 
discussed in the present paper due to scope limitations. 

The service outcomes ‘electricity’ and ‘broadband Internet’ are the results of 
service elements ‘electricity supply’ and ‘broadband access’ respectively. Conse- 
quently we would like to create a service bundle with these service elements. 

Electricity supply has the following functions: 

electricity _supply —> supp contract_electricity_supply 
electricity _supply —> supp billing 
electricity _supply — » supp electricity -transmission 
electricity supply optBund heat_pump 
electricity supply — » optBund energy -control system 
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electricity _supply optBund broadband _access 

electricity _supply —> optBund hot_water 
electricity _supply —> optBund r emote _control 

Consequently, any service bundle for electricity supply needs to include also 
instances of the service elements contract electricity supply, billing and electric- 
ity transmission , and possibly - but not necessarily - any combination of the 
following service elements: heat pump, energy control system, broadband access, 
hot water and remote control. 

Broadband access has the following functions: 
broadband _access -^ SU pp billing 
broadband _access ~^ S upp contracting 
broadband _access — » optBund, electricity _supply 

Consequently, any service bundle for broadband access needs to include also 
instances of the service elements billing and contracting , and possibly electric- 
ity supply. However, since electricity supply is already part of our bundle, this 
function adds no new possibilities. Next, for every service element that we add 
to the bundle due to one of the above functions, we have to check recursively 
whether the functions of that service element pose new restrictions or add new 
possibilities. These service elements are: contract electricity supply, billing, elec- 
tricity transmission and contracting. Three of them (contract electricity supply, 
billing, contracting) have no functions. But electricity transmission does: 
electricity -transmission — >• optBund. electricity supply 
electricity -transmission -^ SU pp contract -electricity -transmission 
electricity -transmission -^ SU pp billing 

The first function need not be addressed, since electricity supply already is 
part of our bundle. Both other functions are of type core/supporting, so their 
second arguments ( contract electricity transmission and billing) must be added 
to any bundle. Since these two service elements have no functions, the recursive 
check of functions terminates, unless we also consider service elements that have 
an optionalBundle function with electricity supply. The result of this process is 
that any service bundle that satisfies the above mentioned requirements must 
include instances of the following nine service elements: (1) one instance of elec- 
tricity supply, (2) one instance of contract electricity supply ; (3) one instance 
of electricity transmission ; (4) one instance of contract electricity transmission ; 
(5) one instance of broadband access', (6) three instances of billing (for electric- 
ity supply, for electricity transmission and for broadband access ); and (7) one 
instance of contracting. 

Assuming that multiple instances exist for all these services (differing in qual- 
ity levels or in other properties) , the configuration process will result in a set of 
possible service bundles. Any such service bundle needs to include nine service 
elements as mentioned. An example for such a service bundle is presented in 
Figure 6. For clarity, we did not model how input/outcome interfaces provide 
the required resources to all service elements. Instead, we modeled only the three 
most important resources: the service input payment and the service outcomes 
electricity and broadband Internet. As can be seen, the resource electricity in a 
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Fig. 6. A service bundle with electricity supply and broadband Internet access 



certain quantity and in state sold is a service outcome of the service element 
electricity supply , as well as a service input of the service element electricity 
transmission. Subsequently, it is also a service outcome of the service element 
electricity transmission (and of the whole bundle), with state transmitted. 
However, more possible service bundles exits. Instances of any of the optionally 
bundled service elements may be added to the bundle. This would require re- 
cursively adding service elements that may be required by the functions of any 
optional service element. For example, the service element hot water would re- 
quire another instance of the service element contracting, and another instance 
of the service element billing. It is important to understand that Figure 6 is not 
a visualization of business processes, but a supplier description of offered ser- 
vices. These will be realized by business processes. There is no 1-on-l mapping 
between service elements and business processes. 

6 Conclusions 

Services have traditionally been subject to research in business science. Discus- 
sions about services, as can be found in the business literature, are characterized 
by the use of natural language, which is not suitable for automated support of 
services. Business knowledge needs to be conceptualized and formalized as a first 
step towards online offering of complex service scenarios. However, scenarios in 
which a variety of services is offered by multiple suppliers require more than a 
formal description of business knowledge. For software to define sets of indepen- 
dent services, it is necessary to describe formally business knowledge on (1) what 
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services are; and (2) under which circumstances services may be sold together. 
In other words, services need to be described as components, and their interde- 
pendencies as constraints. Our service ontology supports these two necessities 
through a formal conceptualization of business knowledge, based on structures 
from the knowledge management literature. 

In this paper we have presented examples of modeling services from the 
energy sector, as part of a large-scale analysis of this sector. Based on our 
component-based description of services in the case study at hand, it seems 
possible to have software that configures service bundles that satisfy customer 
criteria. Currently, we are building in the EC-IST funded project OBELIX a 
tool that (1) allows modeling of elementary service elements and supporting 
constructs, and (2) configures service bundles using these elements as well as 
customer requirements. 

The case study we have presented in this paper is part of a larger case 
study in the energy sector, in which we use other ontologies as well. We also 
investigated how the subjective customer description of services can be mapped 
into an objective supplier description of services; we then combined that process 
with the configuration of services. Among the results were new insights into the 
possible service bundles that are commercially viable for service suppliers, as well 
as feasible in the sense of interdependencies between services. Hence, our service 
ontology can be used not only for a customer-triggered process of configuring 
services, but also for an analysis of possible business scenarios. 
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Abstract. Data integration consists in providing a uniform access to a set of het- 
erogeneous sources through a common representation called global schema. In 
this paper we present DIS@DIS, a data integration system that adopts innovative 
techniques for query answering in a complex integration environment. In particu- 
lar, DIS@DIS is able to deal with integrity constraints, which are used to enhance 
the expressiveness of the global schema. Since data at the sources may not satisfy 
the constraints, DIS@DIS is capable of reasoning in the presence of incomplete 
and inconsistent information, so as to provide consistent answers to user queries. 
Moreover, DIS@DIS is able to deal with both local-as-view and global-as-view 
approaches for the specification of the mapping between the global schema and 
the sources. DIS@DIS incoiporates novel optimization techniques for query pro- 
cessing, which speed up query answering time even in the presence of complex 
global schemata and large amounts of data. Indeed, we show experimental results 
that prove the feasibility of our approach. 



1 Introduction 



The recent development of Information Technology has provided the availability of a 
huge amount of information, stored in sources that are often autonomous, heterogeneous, 
and both physically and logically distributed. Data integration consists in providing a 
uniform access to different sources; it has emerged as an important issue in the areas 
of distributed databases, cooperative information systems, data warehousing, and Web 
data management. 

In data integration [17, 11, 15] the user is offered a common representation of the 
underlying data, called global schema ; the user sees and queries the global schema 
as a single database schema, while the data integration system carries out the task of 
suitably querying the underlying sources and assembling the results in order to answer 
user queries. Integrity constraints are expressed on the global schema to enhance its 
expressiveness, yet the data at the sources may not satisfy such constraints. 

Another crucial aspect of query processing in data integration is the specification of 
the relationship between the global schema and the sources, called mapping. Two basic 
approaches are possible for the mapping: the global-as-view (GAV), in which elements 
of the global schema are associated to views over the sources, and the local-as-view 
(LAV) which requires the sources to be associated to views over the global schema [15]. 

A. Persson and J. Stima (Eds.): CAiSE 2004, LNCS 3084, pp. 51-66, 2004. 
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In this paper we present DIS @ DIS 1 , a system for semantic data integration, that is 
capable of reasoning about integrity constraints in order to improve query answering. A 
significant issue here is that in DIS@DIS it is assumed that the sources are incomplete, 

i.e., they do not provide all information needed to answer user queries. In such a setting, 
due to the presence of integrity constraints, query answering amounts to reasoning about 
inconsistent and incomplete information, which is a difficult task. There are several 
data integration systems in the literature [7, 18, 12, 16, 13, 10,2,4]; yet, to the best of 
our knowledge, only IBIS [4] is able to reason about integrity constraints, though in 
a limited setting w.r.t. DIS@DIS. We emphasize that query processing in DIS@DIS 
is mostly carried out at the intensional (i.e., schema) level; in particular, DIS@DIS 
takes integrity constraints into account by reformulating each user query into a new 
one in which information about integrity constraints is encoded. Keeping most of query 
processing at the intensional level improves efficiency, since the size of the schema and 
constraints is usually much smaller than the size of the data. 

The main innovative and distinguishing features of DIS@DIS are the following: 

1 . DIS @ DIS is able to reason about a very expressive class of constraints in a relational 
setting, namely key dependencies (KDs), inclusion dependencies (IDs), which are 
a generalization of foreign key dependencies, and exclusion dependencies (EDs), 
which establish disjointness between projections on relations. 

2. DIS@DIS deals with incompleteness of data (violations of IDs) by reformulating 
user queries according to the IDs; the technique adopted, based on [6], takes advan- 
tage of novel optimization techniques. 

3. DIS @ DIS is capable of dealing with inconsistencies of data (violations of KDs and 
EDs) on the basis of a novel semantics [6], namely the loosely-sound semantics, that 
allows to obtain consistent answers from inconsistent data. DIS @ DIS implements 
novel optimization techniques for checking the consistency of data, which is a costly 
step in query processing. 

4. DIS @DIS is able to deal with both GAV and LAV mapping specifications. In partic- 
ular, it implements a novel ad-hoc technique for LAV mappings, and, when only IDs 
and EDs are expressed over the global schema, it is able to transform a LAV system 
into a GAV one that is equivalent to the original w.r.t. query answering, thus allow- 
ing for the use of the techniques developed for GAV. The transformation technique 
extends that presented in [3], which does not directly allow for query processing 
and is limited to a restricted form of mapping views. Moreover, the technique of [3] 
works only for LAV integration systems without constraints. 

In order to show the effectiveness and efficiency of the techniques implemented in 
DIS@DIS, we have tested the system in a real-world setting; the experimental results 
have shown that in practical cases DIS@DIS is able to answer queries in reasonable 
time, thus proving the feasibility of our approach. 

The rest of the paper is organized as follows. In Section 2 we present the formal frame- 
work for data integration adopted in DIS@DIS; in Section 3 we present the query an- 
swering techniques of the system; in Section 4 we present the architecture of DIS@DIS; 

1 The name of the system is an acronym for Data Integration System at the Dipartimento di 
Informatica e Sistemistica. 




